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. 용어집 테이블로 정리한다

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

검증 질문:

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

동음이의어 발견 시:

• 각각에 고유한 이름을 부여한다
• 이 구분이 Phase 2 Bounded Context 분리의 단서가 된다

1-2. 비즈니스 규칙과 제약

요구사항에서 규칙을 수집한다.

발견 방법:

• "~할 수 없다", "~이어야 한다", "~인 경우에만" 형태를 찾는다
• 명시된 규칙과 암묵적 규칙 모두 포함

---

Phase 2: Bounded Context (경계 긋기)

"같은 단어라도 맥락에 따라 의미가 달라지는 경계"

경계 판단 기준

Q: 같은 용어가 서로 다른 의미/관심사로 쓰이는 곳이 있는가?
├─ Yes → 별도 Bounded Context
└─ No  → 같은 Bounded Context

예시: "상품(Product)"

• 카탈로그 Context: 이름, 설명, 이미지, 카테고리
• 주문 Context: 가격, 재고, 배송 무게
• 리뷰 Context: 평점, 리뷰 수

같은 "상품"이지만 각 맥락에서 관심 있는 속성과 행위가 다르다.

Context 간 관계

관계	설명	예시
직접 설계	우리가 모델링하는 영역	쿠폰 Context
외부 시스템	ID + 최소 정보만 참조	주문 Context (orderId만)

판단 질문:

• 우리가 직접 설계할 영역은?
• 외부 시스템으로 취급할 영역은?
• 외부에서 필요한 최소 정보는 무엇인가?

---

Phase 3: 경계 안 설계 (전술적 설계)

3-1. Aggregate 경계

"하나의 트랜잭션으로 일관성을 보장해야 하는 단위"

판단 기준:

Q: A를 변경할 때 B도 반드시 함께 변경되어야 하는가?
├─ Yes → 같은 Aggregate
└─ No  → 다른 Aggregate (이벤트로 연결)

Aggregate Root:

• Aggregate의 대표. 외부에서는 Root를 통해서만 내부에 접근한다.
• Root가 내부 요소의 일관성을 보장하는 책임을 진다.

Aggregate가 너무 클 때:

• 서로 다른 생명주기를 가진 부분이 있나?
• 서로 다른 변경 빈도를 가진 부분이 있나?
• 분리해도 불변식을 보장할 수 있는가?

Aggregate가 너무 작을 때:

• 불변식을 보장하기 위해 여러 Aggregate를 동시에 변경해야 하는가?
• 그렇다면 하나로 합쳐야 한다

3-2. Entity vs Value Object

기준	Entity	Value Object
식별자	고유 ID 필요	값 자체로 비교
가변성	시간에 따라 상태 변함	불변 (immutable)
동등성	ID로 비교	모든 필드로 비교
예시	User, Order, Coupon	Money, Address, DateRange

결정 트리:

Q: 이 개념에 고유 식별자가 필요한가?
├─ Yes → Q: 시간에 따라 상태가 변하는가?
│         ├─ Yes → Entity
│         └─ No  → 정말 ID가 필요한지 재검토
└─ No  → Q: 같은 값이면 같은 것으로 취급해도 되는가?
          ├─ Yes → Value Object
          └─ No  → Entity (식별이 필요한 것)

Value Object로 만들 수 있으면 Value Object가 낫다. 이유:

• 불변이므로 부작용 없음
• 테스트가 쉬움
• 공유해도 안전

3-3. 불변식 (Invariant)

"Aggregate가 항상 보장해야 하는 조건"

형식: {Aggregate}의 {조건}은 항상 {보장}이어야 한다

발견 방법:

• Phase 1에서 수집한 비즈니스 규칙에서 "~할 수 없다", "~이어야 한다" 찾기
• 각 불변식이 어느 Aggregate의 책임인지 할당
• 불변식이 Aggregate 경계를 넘으면 → 경계 재검토

검증:

• 이 불변식을 Aggregate Root의 메서드 안에서 보장할 수 있는가?
• 외부 정보 없이 Aggregate 내부만으로 판단할 수 있는가?

3-4. 책임 할당

"정보 전문가 원칙: 그 판단에 필요한 정보를 누가 갖고 있는가?"

판단 흐름:

Q: 이 행위에 필요한 정보를 누가 갖고 있는가?
├─ 단일 Entity/VO가 가짐 → 그 Entity/VO의 메서드
├─ Aggregate Root가 관리 → Aggregate Root의 메서드
├─ 여러 Aggregate에 걸침 → Domain Service
└─ 외부 시스템 정보 필요 → Application Service (Port를 통해)

3-5. Domain Event

"Aggregate 간 비동기 통신 수단"

필요한 경우:

• Aggregate A의 행위 성공 → Aggregate B가 반응해야 할 때
• 같은 트랜잭션에 있을 필요 없는 후속 처리

이벤트 설계 기준:

• 이름: 과거형 동사 (Created, Updated, Deleted)
• 페이로드: 수신자가 필요한 최소 정보만
• 수신자가 발신자의 내부 구조를 알 필요 없어야 함

---

흔한 실수

실수	문제	해결
Phase 2 건너뛰기	경계 없이 모든 것이 한 덩어리	동음이의어가 있으면 Context 분리
모든 것을 Entity로	VO가 적합한 것까지 ID 부여	"정말 ID가 필요한가?"
Aggregate가 하나	God Object	변경 빈도와 생명주기로 분리
불변식 누락	비즈니스 규칙 위반 허용	규칙마다 "누가 보장?" 질문
Domain Event에 너무 많은 정보	결합도 증가	수신자 기준 최소 정보
외부 의존을 Domain에	Dependency Rule 위반	Port interface로 역전