9장 : 도메인 모델과 바운디드 컨텍스트

도메인 모델과 경계

• 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다. 따라서 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어줘야 한다.

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

바운디드 컨텍스트

• 바운디드 컨텍스트는 모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.

바운디드 컨텍스트 구현

• 바운디드 컨텍스트는 도메인 모델 뿐 아니라 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함 한다. 즉, 바운드디 컨텍스트는 도메인 기능을 제공하는 데 필요한 모든 요소를 포함한다.

• 각 바운디드 컨텍스트는 도메인에 알맞은 아키텍처를 사용한다.

바운디드 컨텍스트 간 통합

• 두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다.

바운디드 컨텍스트 간 관계

• 바운디드 컨텍스트는 어떤 식으로든 연결되기 때문에 두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺는다. (ex. REST API)

• 상류 컴포넌트는 일종의 서비스 공급자 역할을 하며 하류 컴포넌트는 그 서비스를 사용하는 고객 역할을 한다. 싱루 컴포넌트는 보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개한다.

• 하류 컴포넌트는 상류 서비스의 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해주는 완충지대를 만들어야 한다. 즉, 내 모델이 깨지는 것을 막아주는 안티코럽션 계층에서 두 바운디드 컨텍스트 단의 모델 변환을 처리해주어야 한다.

• 두 바운디드 컨텍스트가 같은 모델을 공유하는 경우도 있다. 두 팀이 공유하는 모델을 공유 커널이라고 부른다.

• 통합하지 않고 서로 독립적으로 모델을 발전시키는 독립 방식이 있다. 독립 방식으로 개발한 두 바운디드 컨텍으트를 통합하기 위해 별도의 시스템을 만들어야 할 수도 있다.

컨텍스트 맵

• 컨텍스트 맵은 바운디드 컨텍스트 간의 관계를 표시한 것이다.