| 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 | 여러 서비스가 같은 테이블 사용 | 데이터 소유권 분리 |
