5. Bounded Context (경계 컨텍스트)

1. Bounded Context (경계 컨텍스트)

1️⃣ Bounded Context란?

1) 정의

• 하나의 도메인 모델이 의미를 가지는 “경계”

• 같은 단어라도 컨텍스트(맥락)에 따라 의미가 달라지기 때문에
그 의미를 명확하게 구분하는 영역

2) 한 줄 핵심

2️⃣ 왜 필요한가?

1) 문제 상황

2) 문제점

• 하나의 모델로 합치면
• 필드가 계속 늘어남
• 로직 충돌
• 유지보수 지옥

3) 해결

[주문 컨텍스트] → 주문 생성
[결제 컨텍스트] → 결제 처리
[배송 컨텍스트] → 배송 관리

3️⃣ 핵심 개념 (중요)

1) 컨텍스트별로 모델이 다르다

• 주문 컨텍스트

class Order {
    List<OrderItem> items;
    OrderStatus status;
}

• 결제 컨텍스트

class Order {
    Long orderId;
    int totalAmount;
}

👉 완전히 다른 모델임 (이게 핵심)

2) 컨텍스트 간 독립성

• 서로 내부 구조 몰라도 됨

• 필요한 정보만 주고받음

3) 경계 안에서는 언어 통일

• 주문 컨텍스트: “주문 생성”

• 결제 컨텍스트: “결제 승인”

4️⃣ Bounded Context vs MSA (중요)

1) 관계

2) 관계 정리

• 이상적인 구조

Bounded Context 1 → 서비스 1
Bounded Context 2 → 서비스 2

• 현실
• 하나의 서비스에 여러 컨텍스트
• 또는 하나의 컨텍스트를 여러 서비스로 쪼갬

5️⃣ 컨텍스트 간 통신 방식

1) API 호출

Order → Payment API 호출

2) 이벤트 기반 (추천)

OrderCreated 이벤트 발생
→ Payment 서비스가 구독

6️⃣ 실무 예시

❌ 하나로 만든 경우

ReservationService
 - cancel()
 - approve()
 - refund()

✅ Bounded Context 적용

[예약 컨텍스트]
 - 예약 생성, 취소 요청

[관리자 컨텍스트]
 - 취소 승인

[결제 컨텍스트]
 - 환불 처리

• 흐름

1. 예약 취소 요청
2. 관리자 승인
3. 환불 처리

➡️ 각 컨텍스트가 자기 책임만 가짐

7️⃣ 장점 / 단점

✅ 장점

• 복잡한 시스템 분리 가능

• 팀 단위 개발 가능

• 유지보수 쉬움

• MSA로 확장 용이

❌ 단점

• 설계 난이도 높음

• 초기 분석 필요

• 컨텍스트 경계 잘못 잡으면 오히려 더 복잡

8️⃣ 한 줄 핵심 정리

🔥 중요한 포인트 (실무 감각)

1) “같은 이름 = 같은 모델”이 아니다

2) Service 기준으로 나누지 말고

3) DB 기준으로 나누면 망한다