Domain-Driven Design (DDD)

📌 Brief Summary

Domain-Driven Design(DDD)은 복잡한 비즈니스 로직을 애플리케이션의 중심에 두고, 기술 팀과 도메인 전문가 간의 긴밀한 협력을 통해 실제 비즈니스 프로세스를 반영하는 소프트웨어 설계 접근 방식이다 [1, 2]. 개발자와 이해관계자가 소통하는 공통의 어휘인 '유비쿼터스 언어'를 바탕으로 거대한 시스템을 관리 가능한 하위 도메인인 '바운디드 컨텍스트'로 분할한다 [1, 3, 4]. 코드베이스 읽기 관점에서 DDD는 기술적 계층이 아닌 비즈니스 용어로 명명된 모듈 구조를 가지므로, 개발자가 코드의 세부 구현에 매몰되기 전에 비즈니스 의도를 먼저 파악할 수 있는 인지적 기반을 제공한다 [5].

📖 Core Content

유비쿼터스 언어 (Ubiquitous Language): DDD의 목표는 개발자와 비즈니스 이해관계자 간의 커뮤니케이션 격차를 해소하는 공유 언어를 만드는 것이다 [1]. 이 언어는 모든 프로젝트 참여자가 사용하며 대화, 문서뿐만 아니라 코드 자체에도 동일하게 적용되어 시스템 내의 모호함을 줄인다 [6, 7].
바운디드 컨텍스트 (Bounded Context): 크고 복잡한 시스템을 '주문 관리', '고객 지원' 등 작고 관리하기 쉬운 하위 도메인으로 나눈 논리적 경계다 [3]. 각 컨텍스트는 고유한 모델과 유비쿼터스 언어를 가지며, 모델의 중첩을 막아 아키텍처를 깔끔하게 유지한다 [4, 7].
엔티티(Entities)와 값 객체(Value Objects): DDD는 도메인 모델 내에서 고유한 식별자를 가진 '엔티티(예: Customer)'와 오로지 속성으로만 정의되는 '값 객체(예: ShippingAddress)'를 명확히 구분하여 설계한다 [3, 5].
애그리거트 (Aggregates): 하나의 단일 단위로 취급될 수 있는 도메인 객체들의 군집(예: Order와 하위의 OrderLineItem)을 의미한다 [3, 5]. 애그리거트의 루트 객체는 해당 클러스터 전체의 일관성을 보장하며 트랜잭션 관리를 단순화하는 역할을 한다 [3].
코드베이스 구조와 의도 파악: DDD가 적용된 코드베이스는 기술적인 기능이 아닌 비즈니스 용어를 중심으로 폴더와 모듈이 구성되어 있다 [5]. 이러한 특징 덕분에 새로운 개발자는 상세 로직보다 비즈니스 의도와 전체 구조를 하향식으로 더 빠르게 파악할 수 있다 [5, 8].

⚖️ Trade-offs & Caveats

높은 구현 및 설계 복잡성: 심층적인 도메인 모델링과 비즈니스 요구사항 분석을 수반하므로 아키텍처를 구현하고 컨텍스트 경계를 설계하는 과정 자체가 매우 까다롭고 어렵다 [7, 9].
리소스와 시간 소모: 도메인 전문가와의 지속적인 협업 워크샵(Event Storming 등), 모델 분석, 그리고 유비쿼터스 언어 구축에 많은 시간과 숙련된 개발자의 자원이 요구된다 [6, 9].
적용 영역의 제한: 금융, 헬스케어, 이커머스 시스템과 같이 비즈니스 도메인 규칙이 복잡한 프로젝트에서 최상의 결과를 낸다 [9]. 비즈니스 로직이 단순한 애플리케이션에 DDD를 도입할 경우 오히려 불필요한 엔지니어링 오버헤드와 과도한 구조적 복잡성을 초래할 수 있다 [9].

🔗 Knowledge Connections

[아키텍처 및 설계 원칙]

Bounded Context
- 연결 이유: DDD의 가장 핵심적인 패턴으로, 거대한 코드베이스를 명확한 경계를 지닌 개별 모듈로 분해하는 기준을 제공하기 때문이다 [3, 7].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 마이크로서비스 또는 모듈러 모놀리스 환경에서 복잡한 시스템이 서로 간섭 없이 독립적으로 개발 및 유지보수되는 논리적 분리 원리 [4, 7, 10, 11].
Clean Architecture
- 연결 이유: 순수한 비즈니스 규칙(Entities 및 Use Cases)을 UI나 데이터베이스 같은 외부 프레임워크로부터 격리하는 접근법으로, DDD가 추구하는 핵심 도메인 로직의 보호와 시너지를 내기 때문이다 [6, 12].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시스템 내에서 도메인 모델이 외부 인프라의 변화에 영향받지 않도록 의존성을 역전(Dependency Rule)시키는 코드 패키징 기법 [12, 13].

[분석 도구 및 방법론]

Event Storming
- 연결 이유: 비즈니스 도메인을 탐색하기 위해 기술 팀과 도메인 전문가가 협력하여 도메인 이벤트, 명령, 애그리거트를 빠르게 식별하는 워크샵 기법이기 때문이다 [6].
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스에 존재하게 될 유비쿼터스 언어와 도메인 모델 구조가 실제 업무 프로세스에서 어떻게 도출되는지에 대한 형성 맥락 [6].

Deeper Research Questions

DDD의 '유비쿼터스 언어'가 팀의 의사소통을 넘어 실제 코드의 클래스명, 변수명, 디렉토리 구조에 어떻게 물리적으로 맵핑되며 코드 가독성을 개선하는가?
바운디드 컨텍스트(Bounded Context) 간의 데이터 참조나 호출이 필요할 때, 이들의 관계를 정의하는 컨텍스트 매핑(Context Mapping)은 실제 코드에서 어떤 구조(인터페이스, 이벤트 등)로 구현되는가?
기존의 데이터베이스 테이블 중심(Data-driven)으로 설계된 거대한 레거시 코드베이스를 도메인 중심(Domain-driven) 모듈 구조로 전환하기 위한 가장 안전하고 효율적인 마이그레이션 전략은 무엇인가?
애그리거트(Aggregate) 단위가 분산 시스템이나 마이크로서비스 아키텍처 환경 내에서 데이터의 트랜잭션 무결성과 일관성을 어떻게 보장하는가?
코드베이스 디렉토리 구조가 철저히 비즈니스 도메인(예: '결제', '배송')을 기준으로 분리되었을 때, 엔지니어가 코드의 진입점(Top-Down)부터 영속성 계층(Bottom-Up)까지 추적하는 탐색 워크플로우는 기존 아키텍처와 어떻게 달라지는가?

Practical Application Contexts

Implementation: 핵심 도메인 로직을 외부 인프라 구조 및 데이터베이스 관심사와 격리하여, 테스트가 쉽고 유지보수성이 높은 순수한 비즈니스 모델로 코드를 작성한다 [6].
System Design: 큰 시스템을 기술적 계층이 아닌 비즈니스 기능(Capability) 단위로 분해하므로, 시스템 확장 시 마이크로서비스 아키텍처나 모듈러 모놀리스 아키텍처로 안전하게 분할하는 청사진이 된다 [11, 14].
Operation / Maintenance: 각각의 도메인(바운디드 컨텍스트)이 분리되어 있으므로 특정 비즈니스 로직에서 발생한 버그나 장애가 전체 시스템으로 전파되는 것을 막고, 독립적인 단위 테스트를 통해 부분적 개선이 수월하다 [10].
Learning Path: 복잡한 레거시나 대규모 시스템에 새로 온보딩하는 개발자는 특정 함수나 로직에 갇히기보다, 디렉토리에 명명된 유비쿼터스 언어를 바탕으로 비즈니스의 역할과 책임을 우선 파악하는 하향식 독해를 훈련할 수 있다 [5, 8].
My Project Relevance: 엔터프라이즈 시스템의 코드베이스나 규모가 큰 모놀리스 시스템을 해독하고 구조를 파악할 때, 코드 내의 모듈이 왜 특정 비즈니스 도메인 단위로 묶여 있는지 의존성 규칙을 이해하는 결정적인 렌즈로 활용된다 [5].

Adjacent Topics

Microservices Architecture
- 확장 방향: DDD의 바운디드 컨텍스트 단위로 식별된 도메인이 어떻게 개별적이고 독립적인 배포 단위인 마이크로서비스로 전환되어 서비스 간 느슨한 결합을 이루는지에 대한 아키텍처적 확장 [11, 14].
Layered Architecture
- 확장 방향: 코드를 수평적인 책임(UI, Business Logic, Data Access)으로 분리하는 전통적 접근법과 비교하여, 도메인 중심 구조가 계층 간 소통에 어떠한 차이를 만드는지 이해를 돕기 위한 구조적 패턴 탐색 [15-17].

Last updated: 2026-05-02

8.7 KiB Raw Blame History