도메인 주도 설계 입문

학습 목표

도메인 주도 설계(DDD) 가 복잡한 비즈니스에서 경계·언어·모델을 맞추는 접근임을 설명할 수 있다.

Bounded Context가 모델·용어·책임의 경계임을 설명할 수 있다.

Ubiquitous Language가 개발·도메인 공통 언어를 만드는 방법임을 설명할 수 있다.

Context Map으로 컨텍스트 간 관계를 그리고 통합 전략을 고를 수 있다.

문제 상황

• Customer entity 하나 — 마케팅·주문·배송·정산이 같은 테이블 공유
  • 마케팅 필드 추가 → 배송 batch 깨짐
• 회의에서 "Product" — 기획은 진열, 개발은 SKU, 창고는 박스 단위
  • 같은 단어, 다른 의미 — 요구사항 오해
• MSA로 쪼갰는데 공유 DB + 공유 DTO — distributed monolith
• order 모듈이 payment entity import — bounded context 없음
• Context Map 없이 integration — 누가 upstream인지 몰라 API 역전

결합도·응집·by feature까지 봤다. DDD는 왜 그 경계를 어디에 두는지 언어로 고정하는 방법이다.

1. DDD 한눈에

도메인 주도 설계(Eric Evans) — 소프트웨어 구조·언어를 비즈니스 도메인에 맞춘다.

핵심 개념	한 줄
Domain	소프트웨어가 풀려는 문제 영역 (주문, 결제, 배송…)
Model	도메인 이해를 코드·다이어그램으로 표현
Bounded Context	일관된 모델·용어가 유효한 경계
Ubiquitous Language	팀·도메인 전문가 공통 용어
Context Map	컨텍스트 간 관계·통합 지도

• DDD = 전술(tactic) + 전략(strategy) — 이번 편은 전략 입문 (경계·지도)
• Evans — 큰 모델 하나보다 작은 모델 여러 개 + 명시적 관계

2. Bounded Context

Within a boundary, a model is consistent.

Bounded Context(BC) — 특정 유비쿼터스 언어와 도메인 모델이 내부에서 일관되게 통하는 경계.

같은 단어, 다른 모델

컨텍스트	"Product" 의미	핵심 속성
Catalog	진열·검색 대상	title, category, image
Sales	판매 SKU	price, stock reservation
Shipping	포장·운송 단위	weight, dimensions

• 하나의 Product 테이블에 전부 넣으면 — 모든 팀이 한 aggregate에 coupling
• BC마다 자기 모델 — Sales의 Product와 Shipping의 Product는 다른 타입 (ID로만 연결)

BC와 아키텍처

BC	코드·배포 대응
모놀리스	패키지·모듈 경계 (sales/, shipping/)
MSA	서비스 후보 (DB per context)
팀	Conway — BC ≈ ownership 단위

• Shared kernel 최소화 — 진짜 공통(value object)만
• Anti-corruption layer(ACL) — 외부 모델이 내 모델을 오염시키지 않게 변환

3. Ubiquitous Language

Use the language of the domain everywhere.

유비쿼터스 언어 — 개발자·기획·운영·도메인 전문가가 같은 단어로 같은 의미를 쓰게 한다.

나쁜 예	좋은 예 (Sales BC)
OrderDTO, saveRecord	Order, placeOrder
status = 3	OrderStatus.SHIPPED
기술 회의만 영어/약어	코드·테스트·회의 동일 용어

// Sales bounded context — terms match workshop language
public final class Order {
    private final OrderId id;
    private OrderStatus status;

    void ship(ShipmentReference ref) {
        if (status != OrderStatus.PAID) {
            throw new IllegalStateException("cannot ship unpaid order");
        }
        status = OrderStatus.SHIPPED;
        // domain event OrderShipped ...
    }
}

• Glossary 문서 — BC 안에서만 유효한 정의
• 번역 레이어 — integration DTO와 domain 분리 (ACL)

4. Context Map

Context Map — BC들 사이 관계를 그림·표로 명시한다.

관계 (Evans)	의미	예
Partnership	두 BC 동시 변경 협력	Sales ↔ Promotion
Customer-Supplier	Upstream이 downstream 요구 반영	Sales → Billing
Conformist	Downstream이 upstream 모델 그대로	외부 PG conform
Anticorruption Layer	Upstream 모델 번역 후 사용	레거시 ERP → Sales
Open Host Service	공개 프로토콜 (REST, 이벤트)	Catalog API
Published Language	OHS의 표준 포맷	ProductListed event

Catalog --[published language]--> Sales
Sales --[customer-supplier]--> Billing
Sales --[customer-supplier]--> Shipping
Legacy ERP --[ACL]--> Sales

• Upstream — 변경 주도권; downstream은 적응
• Map 없으면 암묵적 conformist — 레거시 DTO가 전역 standard가 됨
• code/context-map-example.md — 관계 표 예시

5. Part 3와 연결

이전 편	DDD
by feature	BC ≈ feature 경계
결합도	BC 간 port·event, 공유 DB 지양
MSA 분해	capability + BC
EDA	BC 간 integration — 이벤트 + published language
헥사고날	BC 안 포트·어댑터

• DDD는 모놀리스에서도 BC 패키지로 시작 — MSA는 증거 있을 때

6. 실무 팁

단계	행동
1	이벤트 스토밍·워크샵 — 동사·명사 후보 수집
2	Glossary — BC별 용어 정의
3	Context Map 초안 — upstream/downstream
4	코드 — package by BC, integration ACL
5	재검토 — 분기마다 map·경계 갱신

함정	대응
BC = 팀 수만큼 쪼개기	모델 경계 기준
Anemic + DDD 용어만	행동 있는 domain model
Map 문서만	ArchUnit·모듈 의존으로 검증
전역 God entity	BC별 translation

7. 정리

• Bounded Context — 일관된 모델·언어의 경계; 같은 단어 다른 모델 OK
• Ubiquitous Language — 코드·회의·문서 동일 용어
• Context Map — BC 관계·통합 전략 (CS, ACL, OHS…)
• 모놀리스·MSA·팀 경계와 정렬하는 전략 DDD
• Part 3 마무리 — Part 4부터 분산 아키텍처

다음에 다룰 것

• 분산 시스템 기초
• Scale up/down, load balancing, stateless vs stateful

---

해당 내용은 Domain-Driven Design (Eric Evans) 및 Fundamentals of Software Architecture (Mark Richards, Neal Ford) 의 내용을 기반으로 합니다.