129. 도메인 주도 설계 (DDD: Domain-Driven Design)

핵심 인사이트 (3줄 요약)

본질: 도메인 주도 설계 (DDD, Domain-Driven Design)는 비즈니스 도메인의 복잡성을 소프트웨어로 직접 반영하기 위해, 비즈니스 전문가(도메인 전문가)와 개발자가 유비쿼터스 언어(Ubiquitous Language)를 공유하고, 바운디드 컨텍스트(Bounded Context), 에그리게이트(Aggregate), 도메인 이벤트(Domain Event)를 핵심 구성 단위로 사용하여 복잡한 엔터프라이즈 소프트웨어를 설계하는 방법론이다.

가치: DDD는 기술 중심이 아닌 비즈니스 도메인 중심 모델링을 강조하며, 유비쿼터스 언어를 통해 비즈니스 의도가 코드에 직접 반영되어 비즈니스 변화에 유연하게 대응하는 아키텍처를 만들어낸다.

판단 포인트: DDD의 전략적 패턴(바운디드 컨텍스트, 컨텍스트 맵, 유비쿼터스 언어)과 전술적 패턴(에그리게이트, 엔티티, 값 객체, 도메인 서비스, 도메인 이벤트)을 혼동하지 않아야 하며, MSA 설계 시 바운디드 컨텍스트가 마이크로서비스 경계의 1차 기준이 된다.

Ⅰ. 개요 및 필요성

DDD는 에릭 에반스(Eric Evans)가 2003년 저서 'Domain-Driven Design'에서 제안한 설계 방법론으로, 복잡한 비즈니스 도메인을 소프트웨어에 정확히 표현하는 것을 목표로 한다.

기존 데이터 중심 설계에서는 CRUD(Create, Read, Update, Delete) 연산을 중심으로 설계하여 비즈니스 의도가 코드에 흐릿하게 표현되었다. DDD는 '도메인 모델'을 소프트웨어의 심장에 놓고, 비즈니스 전문가와 개발자가 같은 언어로 소통하며 그 언어를 코드에 직접 반영한다.

┌─────────────────────────────────────────────────────────────┐
│                DDD 전략적 설계 vs 전술적 설계                 │
├─────────────────────────────────────────────────────────────┤
│  전략적 설계 (Strategic Design)                              │
│  ├─ 바운디드 컨텍스트 (경계 정의)                            │
│  ├─ 유비쿼터스 언어 (공통 언어)                              │
│  └─ 컨텍스트 맵 (BC 간 관계)                                │
│                                                             │
│  전술적 설계 (Tactical Design)                              │
│  ├─ 에그리게이트 (일관성 경계)                               │
│  ├─ 엔티티 + 값 객체                                        │
│  ├─ 도메인 서비스                                           │
│  └─ 도메인 이벤트                                           │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: DDD는 지도 제작과 같다. 전략적 설계는 세계 지도(바운디드 컨텍스트) 수준이고, 전술적 설계는 도시 세부 지도(에그리게이트·엔티티) 수준이다.

Ⅱ. 아키텍처 및 핵심 원리

유비쿼터스 언어 (Ubiquitous Language)는 DDD의 가장 근본적인 실천이다. 비즈니스 전문가가 '주문 확정'이라고 말하면 코드에도 confirmOrder()로 반영하고, '배송 완료' 이벤트는 OrderShippedEvent로 코드화된다. 기술 용어(CRUD)가 아닌 비즈니스 언어가 코드의 1등 시민이 된다.

항목	설명	포인트
바운디드 컨텍스트	도메인 모델의 적용 경계	주문 컨텍스트, 재고 컨텍스트
에그리게이트	일관성 단위 (트랜잭션 경계)	Order + OrderItem
엔티티	고유 식별자를 가진 도메인 객체	Order (orderId)
값 객체	식별자 없이 속성으로 정의	Money, Address
도메인 이벤트	도메인에서 발생한 사건	OrderConfirmedEvent

┌─────────────────────────────────────────────────────────────┐
│          바운디드 컨텍스트 간 관계 (컨텍스트 맵)              │
├─────────────────────────────────────────────────────────────┤
│  [주문 BC] ──공개API──> [재고 BC]                           │
│      │                      │                              │
│  도메인 이벤트            도메인 이벤트                      │
│  (OrderConfirmed)     (StockReserved)                       │
│      │                      │                              │
│  [결제 BC] <──ACL(Anti-Corruption Layer)── [외부 PG 시스템] │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 유비쿼터스 언어는 의사와 간호사가 환자 차트에 의학 용어(표준어)로 소통하듯, 비즈니스 전문가와 개발자가 같은 용어로 소통하여 번역 오류를 없애는 것이다.

Ⅲ. 비교 및 연결

DDD는 복잡한 도메인에서 빛을 발하지만, 단순한 CRUD 시스템에 DDD를 적용하면 오버엔지니어링이 된다. 에릭 에반스도 모든 프로젝트에 DDD가 필요하지는 않다고 했으며, 도메인 복잡성에 따라 적용 수준을 조절해야 한다.

비교 축	A	B
출발점	DB 테이블 구조	비즈니스 도메인 모델
언어	기술 용어 (CRUD)	유비쿼터스 언어 (비즈니스 언어)
변경 용이성	DB 스키마 종속	도메인 모델 중심으로 유연
복잡도	단순 CRUD에 유리	복잡한 도메인에 유리
학습 비용	낮음	높음

📢 섹션 요약 비유: 의사가 환자를 진단할 때, 검사 수치(데이터 중심)보다는 환자의 증상과 병력(도메인 지식)을 먼저 이해해야 정확한 처방(설계)이 가능하다.

Ⅳ. 실무 적용 및 기술사 판단

DDD를 MSA 설계에 적용할 때 가장 중요한 것은 바운디드 컨텍스트와 마이크로서비스 경계의 정렬이다. 하나의 바운디드 컨텍스트는 하나 또는 그 이상의 마이크로서비스로 구현될 수 있지만, 하나의 마이크로서비스가 여러 바운디드 컨텍스트를 포함하면 안 된다.

판단 체크리스트

비즈니스 전문가와 개발자 간에 유비쿼터스 언어가 정의되고 코드에 반영되어 있는가?
바운디드 컨텍스트의 경계가 비즈니스 도메인 기준으로 명확히 정의되어 있는가?
에그리게이트가 트랜잭션 일관성 단위로 올바르게 정의되어 있는가?
컨텍스트 맵이 작성되어 BC 간 관계와 통합 패턴(ACL, Open Host, Shared Kernel)이 정의되어 있는가?
도메인 이벤트가 비즈니스 사건을 정확히 표현하며 이벤트 소싱 또는 Pub/Sub으로 통합되는가?

📢 섹션 요약 비유: 의사(도메인 전문가)와 의무 기록사(개발자)가 같은 의학 용어(유비쿼터스 언어)로 의무 기록(코드)을 작성해야, 다른 의사(팀)가 기록을 읽어도 정확히 이해할 수 있다.

Ⅴ. 기대효과 및 결론

DDD를 적용하면 비즈니스 변화가 코드 변경으로 자연스럽게 이어지는 표현력 있는 도메인 모델이 만들어진다. MSA 설계에서 서비스 경계를 결정하는 가장 강력한 기준을 제공하며, 도메인 이벤트를 통해 서비스 간 결합도를 낮출 수 있다.

한계는 높은 학습 비용, 유비쿼터스 언어 정립을 위한 비즈니스 전문가와의 지속적인 협업 필요, 단순 CRUD 시스템에서의 오버엔지니어링 위험이다.

미래 방향으로는 ① Event Storming 워크숍 방법론과 DDD의 결합, ② CQRS + Event Sourcing과 DDD의 자연스러운 통합, ③ AI 보조 도메인 모델링 도구가 발전하고 있다.

📢 섹션 요약 비유: 도시 설계에서 도로와 건물을 먼저 짓는(기술 중심) 것이 아니라, 시민의 생활 패턴(도메인)을 먼저 분석하여 동선에 맞게 도시를 설계(DDD)하는 것이다.

📌 관련 개념 맵

[비즈니스 복잡성] → [DDD 전략적 설계(BC·유비쿼터스 언어)] → [DDD 전술적 설계(Aggregate·Entity·Event)] → [MSA 서비스 경계] → [CQRS+ES]

개념	연결 포인트
바운디드 컨텍스트	DDD의 전략적 경계 단위, MSA 서비스 경계의 기준
에그리게이트	트랜잭션 일관성 단위, 단일 트랜잭션 내 변경
유비쿼터스 언어	비즈니스 전문가와 개발자의 공통 언어
컨텍스트 맵	BC 간 통합 관계를 시각화한 다이어그램

📈 관련 키워드 및 발전 흐름도

[Object-Oriented Design] → [에릭 에반스 DDD(2003)] → [전략적·전술적 패턴 분리] → [Event Storming 워크숍] → [CQRS+ES 통합] → [AI 도메인 모델링]

👶 어린이를 위한 3줄 비유 설명

DDD는 비즈니스에서 쓰는 말과 코드에서 쓰는 말을 똑같이 맞추는 방법이에요.
'주문 확정'이라는 비즈니스 용어가 코드에도 그대로 confirmOrder()로 나타나요.
이렇게 하면 코드를 읽으면서 비즈니스를 이해할 수 있어요!