1. Bounded Context (경계 컨텍스트)
1️⃣ Bounded Context란?
1) 정의
- 하나의 도메인 모델이 의미를 가지는 “경계”
- 같은 단어라도 컨텍스트(맥락)에 따라 의미가 달라지기 때문에
그 의미를 명확하게 구분하는 영역
2) 한 줄 핵심
“같은 단어라도 의미가 다르면, 다른 컨텍스트로 나눠라”
2️⃣ 왜 필요한가?
1) 문제 상황
예: “Order”
영역 | 의미 |
쇼핑 | 주문 |
물류 | 배송 요청 |
회계 | 결제 내역 |
👉 같은 “Order”인데 의미가 다름
2) 문제점
- 하나의 모델로 합치면
- 필드가 계속 늘어남
- 로직 충돌
- 유지보수 지옥
3) 해결
👉 Bounded Context로 분리
[주문 컨텍스트] → 주문 생성
[결제 컨텍스트] → 결제 처리
[배송 컨텍스트] → 배송 관리3️⃣ 핵심 개념 (중요)
1) 컨텍스트별로 모델이 다르다
같은 “Order”라도 다르게 정의됨
예시
- 주문 컨텍스트
class Order {
List<OrderItem> items;
OrderStatus status;
}- 결제 컨텍스트
class Order {
Long orderId;
int totalAmount;
}👉 완전히 다른 모델임 (이게 핵심)
2) 컨텍스트 간 독립성
- 서로 내부 구조 몰라도 됨
- 필요한 정보만 주고받음
👉 느슨한 결합 (Loose Coupling)
3) 경계 안에서는 언어 통일
👉 유비쿼터스 언어
- 주문 컨텍스트: “주문 생성”
- 결제 컨텍스트: “결제 승인”
👉 같은 단어라도 의미 다르면 분리
4️⃣ Bounded Context vs MSA (중요)
👉 헷갈리는 포인트
1) 관계
개념 | 설명 |
Bounded Context | 설계 개념 |
MSA | 배포/아키텍처 |
2) 관계 정리
- 이상적인 구조
Bounded Context 1 → 서비스 1 Bounded Context 2 → 서비스 2
- 현실
- 하나의 서비스에 여러 컨텍스트
- 또는 하나의 컨텍스트를 여러 서비스로 쪼갬
5️⃣ 컨텍스트 간 통신 방식
1) API 호출
Order → Payment API 호출2) 이벤트 기반 (추천)
OrderCreated 이벤트 발생 → Payment 서비스가 구독
👉 MSA에서 많이 사용
6️⃣ 실무 예시
👉 “예약 취소 → 승인 → 환불”
❌ 하나로 만든 경우
ReservationService
- cancel()
- approve()
- refund()👉 모든 책임이 한 곳 → 유지보수 어려움
✅ Bounded Context 적용
[예약 컨텍스트]
- 예약 생성, 취소 요청
[관리자 컨텍스트]
- 취소 승인
[결제 컨텍스트]
- 환불 처리- 흐름
1. 예약 취소 요청
2. 관리자 승인
3. 환불 처리➡️ 각 컨텍스트가 자기 책임만 가짐
7️⃣ 장점 / 단점
✅ 장점
- 복잡한 시스템 분리 가능
- 팀 단위 개발 가능
- 유지보수 쉬움
- MSA로 확장 용이
❌ 단점
- 설계 난이도 높음
- 초기 분석 필요
- 컨텍스트 경계 잘못 잡으면 오히려 더 복잡
8️⃣ 한 줄 핵심 정리
“모델의 의미가 바뀌는 지점에서 경계를 나누는 것”
🔥 중요한 포인트 (실무 감각)
1) “같은 이름 = 같은 모델”이 아니다
→ 의미 다르면 무조건 분리
2) Service 기준으로 나누지 말고
→ 비즈니스 흐름 기준으로 나눠라
3) DB 기준으로 나누면 망한다
→ 항상 “업무 책임” 기준으로 나눠야 함
Share article