Ddd Context MappingSAFE

An agent skill published by revfactory.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
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. 독립적 저장소 사용 가능
```

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

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

## 서비스 분해 안티패턴

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

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.