ddd-context-mapping

name	ddd-context-mapping
description	DDD(Domain-Driven Design)의 바운디드 컨텍스트 식별, 컨텍스트 맵 작성, 이벤트 스토밍 수행을 위한 상세 방법론. '바운디드 컨텍스트', 'DDD', '도메인 모델링', '이벤트 스토밍', '컨텍스트 맵', '애그리거트 설계', '유비쿼터스 언어' 등 도메인 분석 시 이 스킬을 사용한다. domain-analyst와 service-architect의 도메인 분석 역량을 강화한다. 단, 인프라 배포나 코드 구현은 이 스킬의 범위가 아니다.

DDD Context Mapping — 도메인 주도 설계 컨텍스트 매핑 가이드

바운디드 컨텍스트 식별부터 컨텍스트 맵 작성까지의 체계적 방법론.

이벤트 스토밍 수행 절차

Phase 1: 도메인 이벤트 수집

규칙: 과거형 동사로 표현한다
예: "주문이 생성되었다", "결제가 승인되었다", "배송이 시작되었다"

수집 순서:
1. 핵심 비즈니스 흐름의 이벤트를 시간순으로 나열
2. 예외/실패 이벤트 추가
3. 외부 시스템 이벤트 추가

Phase 2: 커맨드 → 이벤트 매핑

[사용자/시스템] → {커맨드} → [애그리거트] → <<도메인 이벤트>>
[고객]         → {주문 생성} → [Order]    → <<주문이 생성되었다>>
[결제 시스템]   → {결제 승인} → [Payment]  → <<결제가 승인되었다>>

Phase 3: 애그리거트 식별

애그리거트 경계 판단 기준:
1. 트랜잭션 일관성 경계 — 함께 변경되어야 하는 객체 그룹
2. 불변식(Invariant) 보호 — 비즈니스 규칙을 보장하는 단위
3. 동시성 경계 — 동시 접근 시 충돌을 관리하는 단위

Phase 4: 바운디드 컨텍스트 도출

신호	의미
같은 단어가 다른 의미	컨텍스트 분리 필요 (예: "계정" = 사용자계정 vs 금융계정)
다른 팀이 소유	조직 경계 = 컨텍스트 경계
다른 변경 주기	독립 배포 필요 → 분리
다른 데이터 저장소	기술적 경계 = 컨텍스트 경계

컨텍스트 맵 관계 유형

관계	기호	설명	예시
Shared Kernel	SK	공유 도메인 모델	두 팀이 같은 Entity 사용
Customer-Supplier	C/S	상류/하류 관계	주문(상류) → 배송(하류)
Conformist	CF	하류가 상류 모델을 그대로 수용	외부 API 모델 수용
Anti-Corruption Layer	ACL	모델 변환 계층 삽입	레거시 시스템 연동
Open Host Service	OHS	공개 프로토콜 제공	REST API 공개
Published Language	PL	공유 언어(스키마)	Protobuf/Avro 스키마
Separate Ways	SW	독립 운영	통합 불필요
Partnership	P	대등한 협력	두 팀 공동 개발

컨텍스트 맵 예시:

┌─────────────┐     OHS/PL      ┌───────────────┐
│   주문 관리   │ ──────────────→ │   결제 처리     │
│  (Order BC)  │                 │ (Payment BC)   │
└──────┬──────┘                  └───────┬───────┘
       │ C/S                             │ C/S
       ▼                                 ▼
┌─────────────┐     ACL          ┌───────────────┐
│   배송 관리   │ ←───────────── │  외부 PG 연동    │
│ (Shipping BC)│                 │ (3rd Party)    │
└─────────────┘                  └───────────────┘

애그리거트 설계 원칙

크기 결정 기준

작은 애그리거트 선호:
├── 트랜잭션 범위 최소화 → 동시성 충돌 감소
├── 메모리 사용량 감소
└── 변경 영향 범위 축소

예외 (큰 애그리거트 허용):
├── 불변식이 여러 엔티티에 걸침
├── 원자적 일관성이 반드시 필요
└── 최종 일관성으로 대체 불가

애그리거트 간 참조 규칙

✅ ID 참조: Order.customerId (Customer 애그리거트의 ID만 보관)
❌ 직접 참조: Order.customer (Customer 객체를 직접 보관)

이유:
1. 애그리거트 경계 존중
2. 트랜잭션 격리
3. 독립적 저장소 사용 가능

유비쿼터스 언어 사전 템플릿

| 용어 | 컨텍스트 | 정의 | 동의어 | 반의어/혼동 |
|------|---------|------|--------|-----------|
| 주문(Order) | 주문관리 | 고객의 상품 구매 요청 | 오더 | 장바구니(Cart)와 구분 |
| 계정(Account) | 사용자관리 | 로그인 가능한 사용자 단위 | 유저 | 금융계좌와 구분 |
| 계정(Account) | 정산관리 | 정산 대상 금융 계좌 | 계좌 | 사용자계정과 구분 |

서비스 분해 안티패턴

안티패턴	증상	해결
나노서비스	서비스가 너무 작아 1-2개 API만 보유	관련 서비스 병합
분산 모놀리스	모든 서비스가 동기 호출 체인	이벤트 기반 비동기 전환
CRUD 서비스	도메인 로직 없이 DB 프록시 역할	도메인 로직 내재화
God 서비스	하나의 서비스에 과도한 책임	바운디드 컨텍스트 기준 재분해
공유 DB	여러 서비스가 같은 테이블 사용	데이터 소유권 분리