시작하며안녕하세요, 개발자 stark입니다.최근 제가 리더로 있는 개발 동아리 Pulse에서 커플 관련 서비스를 개발하며 DDD를 적용하던 중 흥미로운 논쟁이 있었습니다. "우리는 카카오 로그인만 쓰는데, 회원 정보도 관리해야 하고... 이거 회원 도메인이 일반 서브도메인인가 지원 서브도메인인가?" 단순해 보이는 이 질문이 왜 그렇게 복잡했는지, 저희가 어떤 과정을 거쳐 답을 찾았는지 공유하려 합니다. DDD 개념 간단히 이해하기DDD를 처음 접하면 용어들이 헷갈립니다. 먼저 이것부터 명확히 하고 갑시다. 도메인(Domain)은 우리가 해결하려는 비즈니스 문제 영역 전체입니다. 저희의 경우 "커플 여행 추천 서비스" 자체가 하나의 도메인입니다. 서브도메인(Subdomain)은 이 큰 도메인을 비즈니스..

시작하며안녕하세요. 개발자 stark입니다.저는 최근 1년간 사내에서 헥사고날 아키텍처로 구성된 MSA 프로젝트를 개발했습니다. 그리고 이제 어느 정도 안정화 단계가 되어 지속적으로 프로젝트 구조를 리펙토링 하고 있습니다. 이를 위해 팀 내에서 회의를 9차 정도 진행했는데 그 과정에서 흥미로운 주제로 이야기를 했던 것이 있어서 포스팅을 작성하였습니다. 저희는 시간 날 때마다 아키텍처 관련 얘기를 하곤 하는데 어느 날 선배님께서 이런 주제를 던져주셨습니다. 프로젝트에 헥사고날 아키텍처와 DDD를 적용하기 위해서는 계층 간 역할을 명확하게 분리하여 서로의 침범이 없도록 하는 것이 정말 중요한데 과연 우리는 제대로 구성했을까? 이 주제로 대화를 진행하다 저희의 프로젝트를 다시 분석해 보기 시작했고 그중에서 가..

도메인 모델이란 무엇인가?도메인 모델은 소프트웨어가 다뤄야 할 특정 도메인(업무 영역)을 코드로 표현한 객체 모델(클래스)을 의미합니다. 객체 모델은 도메인을 표현해야 하기 때문에 데이터(필드)와 행동(비즈니스 로직: 메서드)을 모두 포함한다는 것이 핵심입니다. 마틴 파울러는 자신의 블로그에서 “도메인 주도 설계(DDD)는 도메인 모델을 코드로 구현하면서 도메인의 프로세스와 규칙을 풍부하게 이해하는 것에 중심을 둔 소프트웨어 개발 접근법”이라고 설명합니다. 간단히 말해, 도메인 모델은 현실 세계 업무의 중요 개념과 규칙을 소프트웨어 객체에 녹여낸 것입니다. 도메인 모델은 해당 분야의 전문가(도메인 전문가)와 개발자 간의 공통 이해(Ubiquitous Language)를 형성하는 데에도 큰 역할을 합니다...

시작하며 : 왜 전략적 설계가 필요한가?프로젝트 초기에는 모든 기능이 하나의 코드베이스 안에서 개발됩니다. 이때는 기능이 적어 구조가 단순하고 개발 속도도 빠릅니다. 하지만 프로젝트가 성장하면서 기능들이 점점 많아지면, 필연적으로 코드 간의 의존성이 복잡해지기 시작합니다. 예를 들어, '주문' 관련 코드가 '회원'의 등급 정보를 참조하고, '배송' 코드가 다시 '주문'의 상태를 변경하는 등, 각기 다른 기능들이 서로의 내부 로직을 침범하며 뒤죽박죽 얽히게 됩니다. 결국 개발자 한 명이 작은 기능을 하나 수정하기 위해 시스템 전체의 맥락을 파악해야 하는 상황이 오고, 이는 개발 속도를 저하시키고 예측 불가능한 버그를 만들어내는 직접적인 원인이 됩니다. 전략적 설계는 바로 이러한 '의존성의 폭발' 문제를 해..

시작하며안녕하세요. 개발자 stark입니다.최근 DDD관련 책을 읽다가 이런 문구를 봤습니다. "모든 기술적 관심사로부터 비즈니스 로직을 분리하는 것이 포트 앤 어댑터 아키텍처(헥사고날 아키텍처)의 목적이라서 DDD의 비즈니스 로직 구현에 매우 적합하다." 저는 지금 실무에서 헥사고날 + DDD로 개발을 진행하고 있다 보니 이 조합이 비즈니스 로직을 구현하기에 매우 적합하다는 것에는 공감을 했습니다. 근데 스스로에게 "그래서 이게 왜 적합한데?"라고 질문해 봤더니 아무리 생각해도 답이 나오지 않았습니다. 당연히 그럴 수밖에 없었던 게 저는 지금까지 이게 왜 적합한지에 대해서는 단 한 번도 생각해 본 적이 없었던 것입니다. 그냥 적합하다고 하니 "MSA + DDD = 헥사고날 아키텍처" 이렇게 생각하고 사..

시작하며안녕하세요. 개발자 Stark입니다.이번 글의 주제는 도메인 주도 설계(Domain-Driven Design, DDD)를 적용하다 보면 마주치는 중요한 결정 중 하나인 '어떻게 다른 애그리거트(Aggregate)를 참조할 것인가?'입니다. 많은 DDD 전문가들이 작성한 책과 글을 보다 보면 "애그리거트 내부에서는 다른 애그리거트를 ID를 통해 참조하라"라고 조언합니다. 여기서 드는 궁금증은 왜 객체 직접 참조가 아닌 ID 참조를 권장하는 걸까요? 지금부터 그 이유를 명확한 경계 설정과 트랜잭션 관리라는 두 가지 핵심 축을 중심으로 알아봅시다. 애그리거트와 그 경계의 중요성먼저 애그리거트가 무엇인지 간단히 짚고 넘어가겠습니다. 애그리거트(Aggregate)는 쉽게 말해 관련된 데이터와 기능을 하나..

시작하며안녕하세요 개발자 stark입니다.최근 제가 업무 중에 선배님과 애그리거트(Aggregate) 설계에 대한 토의를 하던 중 VO에 대해서 많은 얘기가 오갔습니다. 저희는 어떤 시점에 VO를 어떻게 사용하는 것이 적절한지 얘기를 나누었습니다. 우선 식별자를 통해 값을 구별할 필요가 없다는 것부터 시작해서 VO안에 비즈니스를 담을 수 있고 불변의 장점이 있다는 것까지 얘기가 진행되었습니다. 그런데 얘기를 다 하고 나서 생각해 보니 무언가 핵심을 놓친 것만 같았습니다. 그게 무엇인가 했더니 VO를 어떻게(how) 사용하는지는 알고있는데 왜(why) 사용하는지는 모르고 있었기에 핵심 개념에 대해서는 하나도 얘기를 하지 않았던 것입니다. 그래서 바로 블라드 코노노프가 지은 '도메인 주도 설계 첫걸음'이라는..

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