바운디드 컨텍스트란?

큰 시스템을 여러 개의 작은 컨텍스트로 나누어 각 컨텍스트 내에서 특정한 비즈니스 규칙과 데이터 모델이 적용되는 것을 의미한다.

각 컨텍스트는 독립적으로 설계되고 구현되며, 서로 다른 컨텍스트간에는 인터페이스를 통해 상호작용한다.

도메인 vs 바운디드 컨텍스트 차이

도메인

• 업무 영역, 비즈니스가 해결하고자 하는 문제 영역
• 실제 우리가 시스템으로 풀고자 하는 업무의 개념적 범위

ex. 주문 처리 도메인, 회원 관리 도메인

"무엇을 하는 영역인가?"에 대한 개념적 단위

바운디드 컨텍스트

• 도메인을 바라보는 하나의 해석 / 모델의 경계
• 같은 도메인이라도 상황, 팀, 비즈니스 규칙에 따라 다르게 정의가 가능
• 도메인 모델이 유효하게 작동하는 경계

ex. 주문 처리 도메인이라는 같은 도메인이 있어도..
Order Management : 주문 생성, 주문 상태 변경
Order Payment : 주문 결제 및 결제 상태 관리

"어떻게 나눌 것인가, 어디까지를 하나의 경계로 볼 것인가?"에 대한 실체적 설계 단위

정리

쉽게 비유하자면 도메인 = "의료", 바운디드 컨텍스트 = "내과", "소아과" 등

왜 바운디드 컨텍스트로 나누는가?

모놀리식 문제점

• 서비스 간 결합, 하나의 모델로 모든 도메인을 커버하려다 발생하는 충돌
  (Order가 Product에 의존, Product가 User를 호출하는 식의 순환 구조)

MSA 목적

• 서비스 독립성
• 개발/배포 속도 향상
• 도메인 복잡도 분리

바운디드 컨텍스트 간 통신 방식

API 통신 (동기)

• HTTP RESTful API 사용
  ex. Order -> Product, 가격 확인 API 호출

장점 : 실시간 데이터 조회 가능
단점 : 호출 서비스 장애 시 영향 받음

이벤트 기반 통신(비동기)

• Kafka, RabbitMQ 등 메시지 브로커 사용
  ex. Order 완료 이벤트 발생 -> Payment와 Inventory 서비스 비동기 처리

장점 : 서비스 간 결합도가 낮고, 장애 전파가 없음
단점 : Eventual Consistency 보장, 설계 복잡성 증가
(* Eventual Consistency: 분산 시스템이나 데이터베이스에서 데이터의 일관성을 유지하는 방법)

선택 기준

• 실시간 응답이 필요한 경우 -> API
• 상태 변경/알림이 필요한 경우 -> 이벤트 기반 통신

바운디드 컨텍스트 설계 시 고려사항

도메인 경계 나누는 기준

조직 구조

• 팀별 업무 분리

업무 용어와 의미 차이

• 컨텍스트마다 동일 용어라도 정의가 다르면 나누기

데이터 일관성 요구 수준

• 강한 일관성이 필요한 영역은 같은 컨텍스트

트랜잭션 처리

분산 트랜잭션 문제

• 2PC 활용이나 SAGA패턴 활용

이벤트 기반으로 비동기 상태 동기화

• OrderInventory 이벤트 -> Inventory 차감