바운디드 컨텍스트
바운디드 컨텍스트
바운디드 컨텍스트란 특정 도메인 모델의 경계를 나타내는 개념입니다. 한 개의 바운디드 컨텍스트는 논리적으로 하나의 모델을 갖습니다. 또한 바운디드 컨텍스트는 용어를 기준으로 컨텍스트를 분리할 수 있습니다. 예를들어 사람을 회원 도메인에서는 회원이라 표현하지만 주문 도메인에서는 주문자, 배송 도메인에서는 배송자라고 표현합니다.
이렇게 각각의 도메인마다 사용하는 용어가 다르기 때문에 각 모델은 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야합니다. 만약 도메인 모델이 섞이기 시작한다면 모델의 의미가 약해질뿐 아니라 여러 도메인이 서로 얽히기 때문에 요구사항을 반영하기 힘들고 확장하기 어려운 구조가 됩니다.
바운디드 컨텍스트 모델의 경계
이상적으로 하위 도메인과 바운디드 컨텍스트가 일대일의 관계를 가지면 좋지만 현실적으로는 그렇지 않을 때가 많다고 합니다. 바운디드 컨텍스트는 기업의 팀 조직 구조에 따라 결정되기도 한다고 합니다.
- 주문 도메인을 주문을 처리하는 팀과 결제 금액 계산팀이 따로 있는 경우
- 용어를 명확하게 구분하지 못해 하나의 바운디드 컨텍스트 내부에 두 도메인이 있는 경우
- 규모가 작은 기업에서 전체 시스템을 모놀리식으로 구성한 경우
바운디드 컨텍스트 구현
바운디드 컨텍스트가 도메인 모델만을 표현하는 것은 아니라 합니다. 바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는데 필요한 표현 영역, 응용 영역, 인프라스트럭처 영역을 모두 포함합니다.
바운디드 컨텍스트간 통합
REST API를 호출하여 직접적으로 두 바운디드 컨텍스트를 통합할 수도 있고 메시지 큐를 이용해 간접적으로 두 바운디드 컨텍스트를 통합할 수도 있습니다. 메시지 큐를 이용하는 경우 두 바운디드 컨텍스트가 사용할 메시지의 구조를 맞춰야합니다.
바운디드 컨텍스트간 관계
바운디드 컨텍스트는 어떤 식으로든 연결되기 때문에 두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺습니다. 두 바운디드 컨텍스트간 가장 흔한 관계는 REST API입니다.
💡 관계
- 하류 컴포넌트인 카탈로그는 상류 컴포넌트인 추천 카탈로그에 의존합니다. 카탈로그는 추천 상품을 보여주기 위해서는 추천 바운디드 컨텍스트가 제공하는 REST API를 호출합니다. 이때 추천 바운디드 컨텍스트가 제공하는 API의 인터페이스가 변경되면 카탈로그 컨텍스트의 코드도 변경되게 됩니다.
💡 안티코럽션 계층
- 인프라스트럭처 영역에 있는 구현체 클래스는 외부 시스템과 연동을 처리하는데 외부 시스템의 도메인이 나의 도메인 모델을 침범하지 않도록 막아주는 역할을 수행합니다. 즉, 내 모델이 깨지는 것을 막아주는 안티코럽션 계층이 됩니다. 이 계층에서는 두 바운디드 컨텍스트 간의 모델 변환을 처리해주기 때문에 다른 바운디드 컨텍스트의 모델에 영향을 받지 않고 내 도메인을 유지할 수 있게 됩니다.
컨텍스트 맵
개별 바운디드 컨텍스트에 집중하다보면 전체를 보지 못하는 경우가 발생합니다. 나무만 보고 숲을 보지 못하는 상황을 방지하려면 전체 비지니스를 조망할 수 있는 지도가 필요한데 이것이 컨텍스트 맵입니다.
컨텍스트 맵은 시스템의 전체 구조를 보여줍니다. 이는 하위 도메인과 일치하지 않는 바운디드 컨텍스트를 찾아 도메인에 맞게 바운디드 컨텍스트를 조절할 수 있도록 해줍니다.
