시작하며안녕하세요. 개발자 stark입니다. 테이블을 설계하다 보면 비슷한 개념을 가지는 데이터 모델을 타입 컬럼을 사용해서 분류하고 같은 테이블을 사용하도록 하는 경우가 흔합니다. DDD에서는 이런 식으로 설계된 테이블 모델(Entity)과 도메인 모델(Aggregate)의 개념을 동일하게 적용하면 도메인 모델 내부에 여러 타입의 비즈니스가 쌓이면서 점점 혼잡하고 복잡해지면서 'God Object' 문제가 발생합니다. 저는 실제로 이런 문제를 마주하며 '도메인 모델(Aggregate)을 테이블 모델과 동일시 하는 게 정답일까?'에 대해 매번 고민해 왔습니다. 그리고 이제 생각이 정리되어 이번 포스팅을 작성하게 되었습니다. 포스팅에서는 내용 이해를 위해 'documents(문서)'라는 가상의 테이블을 통..

시작하며안녕하세요. 개발자 stark입니다.최근 제가 현업에서 테스트 코드 작성과 코드 리팩토링을 진행하며 느낀 점들이 굉장히 많습니다. 이전에 프로젝트를 구성했을 때는 비즈니스에서 요구하는 기능을 구현하는 것과 기술적으로 어떤 것을 사용하는 것이 좋을지에 대해 집중했었던 것과 달리 이번 기회에 개발이란 무엇인가에 대해서 정말 많은 고민을 하게 되었고 저 스스로는 어떤 생각을 하며 개발을 해왔는지도 정리할 수 있게 되었습니다. 그래서 이번 포스팅에서는 제가 한 생각들을 조금 회고해보려고 합니다. 완전 개인적인 생각이니 이런 생각도 있구나 하며 재미있게 봐주세요 ㅎㅎ 추상화는 정말 중요하다저에게 추상화는 너무 어렵습니다. 클래스나 메서드 이름을 작명할 때 추상화를 적용하게 되는 경우가 많은데 제가 만든 ..

시작하며안녕하세요. 개발자 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를 '클래스가 한 가지의 일만 해야 한다.'라고 착각하는 경우가 많습니다. 저도 이런 생각을 했던 적이 있었는데 실무에서 코드를 작성하다 보면 잘못된 이해 때문에 오히려 코드를 복잡하게 작성하고 있었다는 것을 알게 되었습니다. 잘못된 이해를 가지고 코드를 작성..