본문으로 건너뛰기

바운디드 컨텍스트 문서 작성 가이드

Template​

문서 구조​

도메인 전체를 조망하는 문서:

  1. 도메인 개요 - 전체 비즈니스 목적과 범위
  2. 유비쿼터스 언어 - 도메인 공통 용어
  3. 컨텍스트 목록 - 각 컨텍스트의 책임과 포함 Aggregate

작성 순서​

바운디드 컨텍스트 문서는 다음 순서로 작성:

  1. 이벤트 스토밍 완료 후

    • Context와 Aggregate가 이미 식별됨

  2. 비즈니스 규칙 작성과 병행

    • Context별로 책임을 정리하면서 비즈니스 규칙도 함께 도출

  3. 도메인 모델 작성 전

    • Context 경계가 명확해야 Aggregate 상세 설계 가능

도메인 개요 작성​

비즈니스 목적:

  • 이 도메인이 제공하는 핵심 가치를 명확히
  • "무엇을 위한" 도메인인지 한 문장으로

좋은 예:

  • ✅ "고객지원팀이 효율적으로 아웃바운드 콜을 관리하고 추적하기 위한 도메인"
  • ✅ "사용자의 주문부터 결제, 배송까지 전체 구매 프로세스를 관리하는 도메인"

나쁜 예:

  • ❌ "콜 도메인" (목적 불명확)
  • ❌ "여러 기능을 제공하는 도메인" (너무 모호)

도메인 범위:

  • 포함하는 것: 이 도메인이 다루는 영역
  • 포함하지 않는 것: 명시적으로 제외되는 영역 (다른 도메인 소관)

작성 예시:

**포함:**
- 아웃바운드 콜 계획 및 실행
- 콜 결과 기록 및 이력 관리
- 콜 관련 메모 작성

**제외:**
- 고객 정보 관리 (User Domain 소관)
- 알림 발송 (Notification Domain 소관)

유비쿼터스 언어 작성​

작성 원칙:

  • 도메인 전체에서 일관되게 사용하는 핵심 용어만
  • 팀 전체(개발자, 기획자, 도메인 전문가)가 동의한 용어
  • 기술 용어가 아닌 비즈니스 용어

포함해야 할 용어:

  • 도메인의 핵심 개념 (예: 콜, 주문, 회원)
  • 중요한 행위 (예: 완료, 취소, 승인)
  • 상태 (예: 활성, 비활성, 대기)
  • 역할 (예: 운영자, 관리자)

제외해야 할 용어:

  • 기술 용어 (Repository, Service, Controller)
  • 구현 상세 (API, Database, Queue)
  • 너무 일반적인 용어 (데이터, 시스템)

작성 예시:

| Term | Definition |
| --- | --- |
| 콜 (Call) | 고객에게 전화를 거는 아웃바운드 활동 |
| 콜 계획 (Call Plan) | 특정 고객에게 콜을 수행하기 위한 계획 |
| 운영자 (Operator) | 콜을 수행하는 직원 |

피해야 할 예:

| Term | Definition |
| --- | --- |
| API | 서버와 통신하는 인터페이스 | ❌ 기술 용어
| 데이터 | 저장되는 정보 | ❌ 너무 일반적

컨텍스트 목록 작성​

Context 식별:

  • 이벤트 스토밍에서 도출한 Context 사용
  • 이벤트 클러스터링, 유비쿼터스 언어 경계 등 참고

책임 작성:

  • 이 Context가 담당하는 핵심 기능 나열
  • 동사 중심으로 명확하게 ("~관리", "~처리", "~제공")
  • 3~5개 정도가 적당

좋은 책임 예:

  • ✅ "고객지원 콜 생성 및 관리"
  • ✅ "콜 완료/취소 처리"
  • ✅ "콜 관련 메모 및 이력 관리"

나쁜 책임 예:

  • ❌ "콜 기능" (너무 모호)
  • ❌ "API 제공" (기술 중심)
  • ❌ "데이터베이스 관리" (구현 상세)

포함 Aggregate 나열:

  • 이벤트 스토밍의 Aggregate 매핑에서 도출한 것 사용
  • Context 내의 모든 Aggregate 나열
  • 간단히 이름만 (상세는 도메인 모델 문서에서)

작성 예시:

## 3.1 Support Context

**책임:**
- 고객지원 콜 생성 및 관리
- 콜 완료/취소 처리
- 콜 관련 메모 및 이력 관리

**포함 Aggregate:**
- AppUserOutboundCallPlan
- CallMemo
- CallHistory

**관계**
- 의존: User Context (사용자 활성 상태 확인, 사용자 정보 조회)
- 발행: Notification Context (알림 발송 요청)

목적: 컨텍스트 간 의존 관계와 통신 방식을 명확히 정의

관계 유형:

  1. 의존 (Depends on)

    • 다른 Context의 데이터나 API를 호출하여 사용
    • 동기적 통신 (HTTP, gRPC)
    • 상대 Context가 없으면 동작 불가
    • 예: Support Context → User Context (사용자 정보 조회)

  2. 발행 (Publishes to)

    • 이벤트를 다른 Context로 발행
    • 비동기적 통신 (Message Queue, Event Bus)
    • Fire-and-forget (상대 처리 결과는 관심 없음)
    • 예: Support Context → Notification Context (콜 완료 알림)

  3. 구독 (Subscribes from)

    • 다른 Context에서 발행한 이벤트를 받아서 처리
    • 비동기적 통신
    • 이벤트 기반 반응
    • 예: Support Context ← User Context (사용자 상태 변경)

작성 팁:

  • 괄호 안에 구체적인 사용 사례나 이벤트명 명시
  • 양방향 관계는 각 Context에 모두 기록
  • 의존이 너무 많으면 Context 분리 재검토