design-ddd

name	design-ddd
description	DDD 도메인 모델링 판단 기준. `/design` command의 D step에서 도메인 복잡도가 높을 때 참조.

Design DDD — 도메인 모델링 판단 기준

/design command의 D step에서 도메인이 복잡할 때 참조하는 판단 기준.

사용 방법:

• /design command의 D step에서 자동 참조됨
• 단독 참조도 가능 (도메인 모델 리뷰 시)

DDD 딥다이브 진입 조건

아래 중 2개 이상 해당하면 DDD 딥다이브가 필요하다:

• 상태 전이가 있다 (예: Draft → Active → Expired)
• 비즈니스 규칙이 3개 이상이다
• 여러 엔티티 간 불변식이 존재한다
• "~할 수 없다" 형태의 제약이 많다

설계 Phase 개요

Phase 1: 용어와 규칙을 모은다 (비즈니스 이해)
         ↓
Phase 2: 의미가 달라지는 경계를 긋는다 (Bounded Context)
         ↓
Phase 3: 경계 안에서 구체적으로 설계한다
         - 함께 변해야 하는 것을 묶고 (Aggregate)
         - 대표를 세우고 (Aggregate Root)
         - ID가 필요한 것(Entity)과 값인 것(VO)을 구분하고
         - 깨지면 안 되는 규칙을 정하고 (Invariant)
         - Aggregate 간 통신 방법을 정한다 (Domain Event)

---

Phase 1: 용어와 규칙 (비즈니스 이해)

1-1. 유비쿼터스 언어 (Ubiquitous Language)

"도메인 전문가와 개발자가 같은 단어를 같은 뜻으로 쓴다"

도출 방법:

1. 요구사항에서 핵심 명사(개념)와 핵심 동사(행위)를 뽑는다
2. 용어집 테이블로 정리한다

용어	정의	예시
{명사}	{한 문장 정의}	{구체적 예}
{동사}	{어떤 상태를 어떻게 바꾸는가}	{구체적 예}

검증 질문:

• 이해관계자가 실제로 쓰는 단어인가?
• 같은 것을 다른 이름으로 부르고 있지 않은가? (동의어 → 하나로 통일)
• 하나의 단어가 문맥에 따라 다른 의미를 가지지 않는가? (동음이의어 → 분리)

동음이의어 발견 시:

• 각각에 고유한 이름을 부여한다