[DDD] 바운디드 컨텍스트(Bounded Context)

본 포스팅은 DDD 를 공부하면서 정리하기 위한 포스팅입니다.

출처: 도메인 주도 개발 시작하기 - DDD 핵심 개념 정리부터 구현까지 (저자. 최범균)

---

1. 바운디드 컨텍스트(Bounded Context)

하나의 큰 도메인은 작은 여러 개의 하위 도메인을 가질 수 있습니다. 이 과정에서 각자 다른 도메인이지만, 같은 용어를 다른 의미로 사용하는 경우가 있습니다.

예를 들어, 온라인 쇼핑몰 이라는 하나의 큰 도메인에 회원 도메인과 주문 도메인이 하위 도메인으로 존재한다고 가정해보겠습니다.

그리고 각 도메인에 아래와 같은 기능이 존재한다고 해보겠습니다.

• 회원 도메인 : 쇼핑몰 회원이 자신의 회원정보를 변경할 수 있다.
• 주문 도메인 : 쇼핑몰 회원은 상품 주문 시, 배송지를 변경할 수 있다.

두 도메인 모두 "회원" 이라는 용어가 언급되고, 쇼핑몰을 이용하는 사용자 라는 관점에서는 같은 의미라고 생각될 수 있습니다.

하지만, 이를 도메인 모델로 도출하는 과정에서 두 용어는 다른 의미를 가질 수 있습니다.

회원 도메인에서의 회원은 이름 / 연락처 / 이메일주소 / 로그인아이디 / 로그인비밀번호 등 회원 자체의 정보를 의미하는 반면,

주문 도메인에서의 회원은 이름 / 연락처 / 주소 등 주문자의 정보를 의미합니다.

 

이처럼, 같은 용어를 사용하더라도 도메인의 의미는 모델에 따라 달라질 수 있습니다.

주문 도메인에서의 회원은 주문이라는 비지니스 흐름 내에서 명확한 의미를 가지고, 회원 도메인에서의 회원 또한 회원 이라는 비지니스 흐름 내에서 그에 따른 명확한 의미를 가지게 됩니다. 회원 이라는 모델의 의미를 명확하게 하기 위해 영역(주문, 회원)이 필요합니다.

이런 영역을 DDD 에서 바운디드 컨텍스트(Bounded Context) 라고 합니다.

 

2. 바운디드 컨텍스트 구현

하나의 바운디드 컨텍스트는 도메인 계층 뿐만이 아닌 표현계층 부터 인프라 계층, 데이터 저장소 까지 전 계층을 포함합니다.

바운디드 컨텍스트는 도메인 기능을 제공하기 위해 필요한 모든 구성요소를 포함한다.

도메인 모델이 변경되는 경우, 데이터 구조가 변경되면 데이터베이스 테이블 스키마가 변경될 수 있어 데이터저장소 또한 바운디드 컨텍스트에 포함됩니다.

위와 같은 구조로 바운디드 컨텍스트를 구성한다고 했을 때, 도메인에 따라 바운디드 컨텍스트가 나눠지게 되면, 아래와 같은 구조로 바운디드 컨텍스트들이 구성될 수 있습니다.

온라인 쇼핑몰 이라는 큰 도메인 하위에 다수의 바운디드 컨텍스트를 구현한 형태

얼핏 보면, 하나의 바운디드 컨텍스트가 하나의 도메인으로 구성되어 바운디드 컨텍스트와 도메인이 같은 뜻이라고 오해할 수 있습니다.

하나의 도메인 모델을 하나의 바운디드 컨텍스트로 구현하는 것이 이상적이긴 하지만, 아래와 같은 예외가 있을 수 도 있습니다.

1개의 바운디드 컨텍스트에 2개의 도메인이 구현된다.

3. 바운디드 컨텍스트 간 관계

바운디드 컨텍스트는 쉽게 말하면 "영역" 입니다. 바운디드 컨텍스트를 구성하는데는 여러가지 방법이 있습니다.

하나의 프로젝트에서 논리적으로 패키지를 분리할 수 도 있고, 도메인 마다 프로젝트를 생성해 물리적으로 서비스를 분리할 수 도 있습니다.

두 가지 방법 모두 논리적으로 바운디드 컨텍스트가 명확하게 분리되어 있다면, 아래와 같은 구조를 가지게 될 것 입니다.

 

바운디드 컨텍스트를 명확하게 분리했다면, 데이터 저장소를 공유하지 않게 될 것입니다. 그렇게 된다면, 주문 컨텍스트에선 회원 정보가 필요하거나, 상품 정보가 필요한 경우엔, 주문 컨텍스트에서 회원 혹은 상품 컨텍스트로 필요한 데이터를 요청해야 합니다.

요청을 보내는 관계를 그림으로 나타내면 아래 처럼 나타낼 수 있을 것 입니다.

주문 바운디드 컨텍스트에서 회원/상품 바운디드 컨텍스트로 요청을 보내면 주문 바운디드 컨텍스트는 회원/상품 바운디드 컨텍스트에서 응답해주는 데이터에 의존하게 됩니다. 이 때, 주문 바운디드 컨텍스트는 "하류 컴포넌트", 회원/상품 바운디드 컨텍스트는 "상류 컴포넌트" 가 됩니다.

상류 컴포넌트는 하류 컴포넌트에게 데이터를 공급하고, 하류 컴포넌트는 상류 컴포넌트가 제공한 데이터를 자신의 비지니스에 사용합니다.

위 같이 독립적인 바운디드 컨텍스트 간에 데이터를 공유하기 위해서는 기본적으로 상류 컴포넌트와 하류 컴포넌트가 주고 받는 데이터 구조를 맞춰야 한다는 번거로운 점이 있습니다. 

예를 들어, 주문 바운디드 컨텍스트에서는 상품 바운디드 컨텍스트를 통해 ["상품ID", "상품 가격"] 을 받고 싶어 하는데, 상품 바운디드 컨텍스트에서 ["상품ID", "상품명"] 를 주면, 데이터 구조가 맞지 않아서 정상적으로 로직을 실행할 수 없을 것 입니다. 

이렇게 다른 바운디드 컨텍스트로 부터 받아야할 데이터가 존재한다면, 데이터를 제공하는 바운디드 컨텍스트도 그에 맞게 잘 줘야된다고 생각하는데, 이런 데이터 구조에 대한 정의는 필요합니다.

 

그런데 만약 데이터를 제공하는 곳 즉, 상류  컴포넌트는 1개인데 데이터를 받는 하류 컴포넌트가 많아지면 어떻게 될까요?

심지어 하류 컴포넌트가 각각 원하는 데이터 구조가 다르면... 상류 컴포넌트는 데이터를 필요로 하는 하류 컴포넌트 마다 데이터 구조를 다 정의해서 줘야합니다. 이는 상류 컴포넌트를 개발하는 개발자에게 상당한 부담으로 다가올 수 있습니다.(관리 어떡해....)

 

이런 경우, 상위 컴포넌트에선 필요할거 같은 데이터를 응답 1개로 정의해 해당 데이터를 응답받을 수 있는 요청을 하류 컴포넌트에게 제공하는데 이런 요청을 "공개 호스트 서비스" 라고 합니다.