시작하며안녕하세요. 개발자 stark입니다.오늘은 제가 도메인 주도 설계(DDD)를 하며 Aggregate를 구성할 때 느낀 점을 정리해보려고 합니다. 저는 실무에서도 사이드 프로젝트에서도 DDD로 개발을 진행하고 있습니다. 그런데 도메인에 대한 Aggregate를 구성할 때 매번 하고 있는 고민이 있습니다. 예를 들어 사이드 프로젝트에서 Aggregate Root가 될 PostEntity와 일반 종속 Entity(첨부파일, 해시태그)들을 포함하는 게시글 Aggregate를 하나 구성했습니다. 저는 Spring과 DB접근 라이브러리로 ORM인 JPA를 사용하고 있었기에 엔티티의 관계성을 설정해 줄 필요성이 있었습니다. 근데 여기서 Aggregate Root인 PostEntity만으로 Repository..

시작하며안녕하세요. 개발자 stark입니다!개발을 하다 보면 동일한 기능을 다양한 방법으로 구현해야 하는 상황이 종종 있습니다. 이때 전략 패턴(Strategy Pattern)을 사용하면 코드 구조를 유연하게 하고 재사용성을 높일 수 있습니다. 이번 포스팅에서는 전략 패턴의 개념부터 시작해서 간단한 자바 코드 예제와 스프링 기반 예제까지 살펴봅시다. 디자인 원칙인 '개방-폐쇄 원칙(OCP)'과 '전략 패턴'의 연관성도 함께 설명하여, 자바 백엔드 개발자뿐만 아니라 개발에 입문하시는 분들에게도 도움이 되었으면 좋겠습니다. 전략 패턴의 정의와 목적 (OCP와의 관련성)전략 패턴은 알고리즘 집합을 정의하고 각각을 캡슐화하여, 이들 알고리즘을 상호 교체 가능하게 만드는 디자인 패턴입니다. 쉽게 말해, 실행 시..

데코레이터 패턴이란?데코레이터 패턴(Decorator Pattern)은 객체지향 설계에서 기존 객체의 기능을 수정하지 않으면서 새로운 기능을 동적으로 추가할 수 있게 해주는 구조적 디자인 패턴입니다. 즉, 클래스의 코드를 변경하거나 상속을 통해 서브클래스를 만들지 않고도, 특정 객체에만 새로운 행동을 붙일 수 있습니다 (다른 동일한 클래스의 객체들에는 영향을 주지 않음). 이는 단일 책임 원칙과 개방-폐쇄 원칙을 잘 지원하는데, 각 기능을 별도 클래스로 분리하면서도 기존 코드를 수정하지 않고 확장이 가능하기 때문입니다. 데코레이터 패턴은 상속을 사용한 확장에 대한 유연한 대안입니다. 상속은 컴파일 시점에 정적으로 기능을 추가하며 해당 변경이 그 클래스를 사용하는 모든 인스턴스에 영향을 줍니다. 반면 데코..

시작하며안녕하세요. 개발자 stark입니다!실무에서 이벤트를 설계하다 보면 동료들과 느슨한 결합이나 의존성에 대한 얘기를 많이 하게 됩니다. 저는 이런 대화를 할 수 있다는 것은 이벤트를 활용하는 방식이 아키텍처에서는 굉장히 중요한 역할을 하기 때문이 아닐까 싶은 생각이 들어서 이벤트에 대해서 열심히 공부를 해봤습니다. 그러던 도중 이벤트를 활용하는 게 옵저버 패턴과 관련이 있다는 것을 알게 되었고 좀 더 깊이 알고 싶다는 생각이 들어 정리를 하면서 포스팅을 작성하게 되었습니다. 앞으로 여러 디자인 패턴들을 차근차근 정리해 나갈 예정이니 재미있게 봐주셨으면 좋겠습니다.  옵저버 패턴이란?옵저버 패턴(Observer Pattern)은 하나의 객체 상태 변화가 관련된 여러 객체에 자동으로 전달되어 각 객체가..

시작하며안녕하세요. 개발자 stark입니다. Apache Kafka를 사용하다 보면 메시지 전송 보장 방식(message delivery guarantee)이라는 개념을 접하게 됩니다. 이는 어떤 메시지가 몇 번 전달되는지를 보장하는 방식으로, 애플리케이션이 데이터를 처리하거나 주고받을 때 '중복 처리'나 '데이터 유실'을 어떻게 다룰 것인지를 결정하는 중요한 요소입니다. 이번 포스팅에서는 Kafka의 대표적인 메시지 전달 보장 방식인 At Most Once(최대 한 번), At Least Once(최소 한 번), Exactly Once(정확히 한 번)이 무엇을 의미하는지 기본 개념부터 이해해 봅시다.  메시지 전달 보장 방식이란?'메시지 전달 보장 방식'은 시스템이 메시지를 처리하거나 전달할 때 발생할..

시작하며안녕하세요. 개발자 stark입니다. 최근 Transactional Outbox Pattern에 대한 대화를 하게 되었는데 제가 아직 이 패턴에 대해 모르는 점이 많다는 것을 깨달았습니다. 그래서 이 궁금증을 해결하기 위해 좀 더 깊이 공부해 봤습니다. 특히 이번 포스팅은 이전에 제가 작성했던 outbox 패턴 포스팅의 내용을 기반으로 이어서 설명드릴 예정입니다. 그러니 아래의 포스팅을 꼭 확인해 주세요! [MSA] Transactional Outbox Pattern안녕하세요! 글쓰는 개발자 stark입니다. 저는 최근 1년간 주로 MSA 프로젝트를 진행해 왔는데요 프로젝트를 설계하고 개발하면서 항상 같은 고민을 해왔습니다. 바로 MSA 서버 간 데이터 동기화 방curiousjinan.tistor..

안녕하세요! 개발자 stark입니다. 이번 포스팅은 SOLID 원칙 중 첫 번째인 단일 책임 원칙(Single Responsibility Principle, SRP)에 대한 내용입니다. 굉장히 흔한 지식이지만 로버트 마틴이 작성한 SRP 관련 글을 읽던 중 "각 소프트웨어 모듈은 변경의 이유가 하나여야 한다."라는 다소 추상적인 개념을 보게 되었고 제가 이걸 조금이라도 더 쉽게 이해하고 싶다는 생각이 들어 정리하며 작성하게 되었습니다. 참고로 SRP를 '클래스가 한 가지의 일만 해야 한다.'라고 착각하는 경우가 많습니다. 저도 이런 생각을 했던 적이 있었는데 실무에서 코드를 작성하다 보면 잘못된 이해 때문에 오히려 코드를 복잡하게 작성하고 있었다는 것을 알게 되었습니다. 잘못된 이해를 가지고 코드를 작성..

시작하며안녕하세요, 개발자 stark입니다! 오랜만에 글을 적게 되었는데요. 오늘은 제가 실무에서 가장 많이 고민했던 주제 중 하나인 DDD(Domain-Driven Design)의 애그리게잇 설계에 대해 다뤄보려고 합니다. 특히 Spring과 Java 환경에서 이를 어떻게 효과적으로 구현할 수 있는지, 실제 경험을 바탕으로 공유해 드리겠습니다. 애그리게잇은 DDD에서 가장 핵심적인 개념임에도 불구하고 이를 적절히 설계하는 데 어려움을 겪습니다. 저 같은 경우에는 매번 로직을  작성하면서 "이 엔티티는 어느 애그리게잇에 속해야 할까?", "애그리게잇 경계를 어디까지 설정해야 할까?" 등의 고민이 끊이지 않았습니다. 그래서 오늘은 최대한 실용적인 관점에서 접근해 보겠습니다.  도메인 주도 설계와 애그리게잇..

시작하며안녕하세요 개발자 stark입니다. 이번 포스팅은 gRPC 시리즈의 번외 편입니다. 관련 프로젝트 링크는 하단에 있습니다. GitHub - wlsdks/grpc-client-example: SpringBoot3.x.x 이상 버전의 grpc 예제 프로젝트 (gRPC 서버 코드와 함께 확SpringBoot3.x.x 이상 버전의 grpc 예제 프로젝트 (gRPC 서버 코드와 함께 확인해주세요) - wlsdks/grpc-client-examplegithub.comgRPC 시리즈의 포스팅은 서버 구성으로부터 시작됩니다.아래 포스팅을 통해 gRPC로 MSA 프로젝트 구성하기를 따라가다 보면 위의 링크의 프로젝트가 완성됩니다. 시간이 괜찮으시다면 한 번쯤 읽어보시는 것도 좋을 것 같습니다. 이번 포스팅을 위해..