[도메인 주도 개발 시작하기] 9. 도메인 모델과 바운디드 컨텍스트

1. 도메인 모델과 경계

한 도메인은 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다. 또한 논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 존재한다.

 

하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다. 하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야하고, 각 모델은 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야 한다. 여러 하위 도메인의 모델이 섞이면 모델의 의미가 약해질 뿐만 아니라 여러 도메인의 모델이 서로 얽히기 때문에 각 하위 도메인별로 다르게 발전하는 요구사항을 모델에 반영하기 어려워진다.

 

모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖고, 이렇게 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트(Bounded Context)라고 한다.

 

2. 바운디드 컨텍스트

• 모델의 경계를 결정
• 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖음
• 용어를 기준으로 구분
• 실제로 사용자에게 기능을 제공하는 물리적 시스템으로, 도메인 모델은 바운디드 컨텍스트 안에서 도메인을 구현
• 조직 구조에 따라 바운디드 컨텍스트가 결정
• 한 개의 바운디드 컨텍스트에 여러 하위 도메인이 포함되는 경우, 하위 도메인마다 구분되는 패키지를 갖도록 구현
• 바운디드 컨텍스트는 각자 구현하는 하위 도메인에 맞는 모델을 갖음

 

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

바운디드 컨텍스트는 도메인 모델 뿐만 아니라 도메인 기능을 사용자에게 제공하는 데 필요한 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함한다. 도메인 모델의 데이터 구조가 변경되면 DB 테이블 스키마도 함께 변경해야 하므로 테이블도 포함된다.

 

각 바운디드 컨텍스트는 도메인에 알맞은 아키텍처를 사용하고, 한 바운디드 컨텍스트에서 여러 방식을 혼합해서 사용할 수도 있다(ex. CQRS). 또한 각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수도 있다.

 

마지막으로 바운디드 컨텍스트는 반드시 사용자에게 보여지는 UI를 가지고 있어야 하는 것은 아니고, UI 서버를 통해 간접적으로 브라우저와 통신할 수도 있다.

 

4. 바운디드 컨텍스트 간 통합

온라인 쇼핑 사이트에서 매출 증대를 위해 카탈로그 하위 도메인에 개인하 추천 기능을 도입하기로 했다고 가정했을 때, 카탈로그 하위 도메인에는 기존 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 생긴다.

 

 

두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다. 카탈로그와 추천 바운디드 컨텍스트 간 통합이 필요한 기능은

• 사용자가 제품 상세 페이지를 볼 때, 보고 있는 상품과 유사한 상품 목록을 하단에 보여준다.

와 같다. 사용자가 카탈로그 바운디드 컨텍스트에 추천 제품 목록을 요청하면 카탈로그 바운디드 컨텍스트는 추천 바운디드 컨텍스트로부터 추천 정보를 읽어와 추천 제품 목록을 제공하게 된다.

 

이때 두 바운디드 컨텍스트 간 통합 방식으로, REST API를 호출하는 직접 방식이나, 메시지 큐를 사용하는 간접 방식이 사용될 수 있다.

 

REST API 호출

 

메시지 큐

 

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

바운디드 컨텍스트는 어떤 식으로든 연결되기 때문에 두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺는다. 두 바운디드 컨텍스트 간 관계 중 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계이다. REST API가 대표적이고, 이 관계에서 API를 사용하는 바운디드 컨텍스트는 API를 제공하는 바운디드 컨텍스트에 의존하게 된다.

• 하류 컴포넌트는 상류 컨포넌트가 제공하는 데이터와 기능에 의존한다.
• 상/하류 컴포넌트의 상호작용은 필수적이다.

 

상류 컴포넌트

• 일종의 서비스 공급자 역할
• 보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개한다.
• 하류 컴포넌트가 다수 존재할 때 여러 하류 컴포넌트의 요구사항을 수용할 수 있는 API를 만들고, 이를 서비스 형태로 하류 컴포넌트에게 제공을 하며 서비스의 일관성을 유지한다. => 이러한 서비스를 공개 호스트 서비스(OPEN HOST SERVICE)라고 하고 대표적인 예로 검색이 있다.

 

하류 컴포넌트

• 서비스를 사용하는 고객 역할
• 상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다. 따라서 상류 서비스의 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해주는 완충 지대가 필요하다.

 

공유 커널(SHARED KERNEL)

• 두 바운디드 컨텍스트가 같은 모델을 공유하는 경우도 존재하는데, 이때 두 팀이 공유하는 모델을 지칭
• 두 팀이 하나의 모델을 개발해서 공유하기 때문에 두 팀에서 동일한 모델을 두 번 개발하는 중복을 줄일 수 있는 장점이 있다.
• 하지만 두 팀이 한 모델을 공유하기 때문에 밀접한 관계를 유지해야 하는데, 만약 밀접한 관계를 형성할 수 없다면 공유 커널로 인해 개발이 지연되고 정체되는 문제가 발생할 수 있다.

 

독립 방식(SEPARATE WAY)

• 서로 통합하지 않는 방식으로, 두 바운디드 컨텍스트 간에 통합하지 않으므로 서로 독립적으로 모델을 발전시킴
• 독립 방식에서는 수동으로 바운디드 컨텍스트를 통합, 별도의 시스템을 만들어야 할 수도 있다.

 

6. 컨텍스트 맵

바운디드 컨텍스트 간의 관계를 표시한 것으로, 한눈에 각 바운디드 컨텍스트의 경계가 명확하게 드러나고 서로 어떤 관게를 맺고 있는지 알 수 있다. 바운디드 컨텍스트 영역에 주요 애그리거트를 함께 표시하면 모델에 대한 관계가 더 명확히 드러난다. 

 

컨텍스트 맵

 

컨텍스트 맵은 시스템의 전체 구조를 보여준다. 이는 하위 도메인과 일치하지 않는 바운디드 컨텍스트를 찾아 도메인에 맞게 바운디드 컨텍스트를 조절하고 사업의 핵심 도메인을 위해 조직 역량을 어떤 바운디드 컨텍스트에 집중할지 파악하는 데 도움이 된다.

 

출처 : 최범균, 『도메인 주도 개발 시작하기 DDD 핵심 개념 정리부터 구현까지』, 한빛미디어(2022), p276-p298