[도메인 주도 개발 시작하기] 9. 바운디드 컨텍스트

바운디드 컨텍스트란?

• 어디까지가 같은 도메인 모델을 쓰는 범위인지 정해 놓은 경계
• 같은 용어와 모델이 ‘동일한 의미’로 통용되는 명확한 경계

❌ 바운디드 컨텍스트 없을 때

class Order {
    PaymentStatus paymentStatus;
    DeliveryStatus deliveryStatus;
    BigDecimal settlementAmount;
    String trackingNumber;
}

 

• 주문 + 결제 + 배송 + 정산 다 섞임
• “이 필드 누가 책임지지?”가 불분명

✅ 바운디드 컨텍스트 나눈 후

주문 컨텍스트

Order {
    OrderId
    OrderItems
    OrderStatus
}

 

결제 컨텍스트

Payment {
    PaymentId
    OrderId
    PaymentStatus
}

배송 컨텍스트

Delivery {
    DeliveryId
    OrderId
    Address
    TrackingNumber
}

• 같은 OrderId를 쓰지만 모델은 서로 독립적임

---

바운디드 컨텍스트 vs Aggregate 차이

	바운디드 컨텍스트	Aggregate
레벨	시스템/모델 경계 (거시)	도메인 모델 내부 규칙 단위 (미시)
역할	모델 의미를 보호	불변식(invariant) 보호
범위	서비스/모듈/팀 단위	엔티티 묶음
개수	시스템에 여러 개	컨텍스트 안에 여러 개
바뀌는 이유	의미가 달라질 때	규칙이 함께 깨질 때

Aggregate

• 개념 : 항상 함께 일관성을 유지해야 하는 엔티티 묶음
• 핵심 규칙 : 
  • Aggregate Root만 외부에서 접근
  • 트랜잭션은 Aggregate 단위
  • 불변식은 Root가 책임
  • Aggregate는 단 하나의 바운디드 컨텍스트 안에서만 존재

---

바운디드 컨텍스트 나누는 기준

예: 주문 상태

• 주문: CREATED / PAID / CANCELED
• 배송: READY / SHIPPED / DELIVERED

OrderStatus 하나로 못 묶음 👉 컨텍스트 분리

Aggregate vs 컨텍스트 결정 순서

1️⃣ 바운디드 컨텍스트부터 나눈다(의미/책임 기준)

2️⃣ 각 컨텍스트 안에서 Aggregate를 설계한다