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

9.1 도메인 모델과 경계

 

도메인을 완벽하게 표현하는 단일 모델을 만들려고 하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다.

 

하위 도메인마다 사용하는 용어와 의마가 다르다.

 

올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.  각 모델은 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야 한다.

같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트라고 부른다.

 

9.2 바운디드 컨텍스트

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

 

이상적으로 하위 도메인과 바운디드 컨텍스트가 일대일 관계를 가지면 좋겠지만 현실은 그렇지 않을 때가 많다.

바운디트 컨텍스트가 팀구조에 따라 결정되기도 한다.

 

여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 하위 모델이 섞이지 않도록 해야한다.

전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠지기 쉽지만 결과적으로 도메인 모델이 개별 하위 도메인을 제대로 반영하지 못해서 확장하기 어렵고 서비스 경쟁력을 떨어뜨리게 된다.

 

바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 구현 하는 하위 도메인에 알맞은 모델을 포함한다.

 

9.3  바운디드 컨텍스트 구현

바운디드 컨텍스트는 도메인 모델만 포함하는게 아니라 도메인 기능을 사용자에게 제공하는 모든 것.
즉 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함한다. db 테이블도 포함된다.

 

모든 바운디드 컨텍스트를 도메인 주도로 개발할 필요는 없다.

단순한 로직의 경우 CRUD 방식으로 구현해도 된다.

그리고 서로 다른 바운디드 컨텍스트는 다른 구현 기술을 사용할 수도 있다.

또한 UI를 반드시 가지고 있어야 하는 것은 아니다.

 

9.4 바운디드 컨텍스트 간 통합

바운디드 컨텍스트 간 통합이 필요할 때 예시를 들어주는 부분.

 

** 마이크로 서비스와 바운디드 컨텍스트

개별 서비스를 독립된 프로세스로 실행하고 각 서비스가 REST API 나 메세징을 이용하여 통신하는 구조를 갖는다.

바운디드 컨텍스트는 모델의 경계를 형성하는데 마이크로 서비스로 구현하면 자연스럽게 컨텍스트별 모델이 분리된다.

별도 프로세스로 개발한 바운디드 컨텍스트는 독립적으로 배포하고 모니터링하며 확장된다.

 

9.5 바운디드 컨텍스트 간 관계

바운디드 컨텍스트 간 관계 중 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계이다.

REST API 가 대표적이다. 이 관계에서 사용하는 바운디드 컨텍스트는 제공하는 곳에 의존하게 된다.

 

상류 컴포넌트 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다. 따라서 하류 컴포넌트는 상류 서비스의 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해 주는 완충 지대를 만들어야 한다.

 

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

중복 설계를 막을 수 있고, 한 팀에서 임의로 모델을 변경하면 안된다.

 

9.6 컨텍스트 맵

개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못하는데 그걸 방지하는 전체 비지니스 지도가 있다 그걸 컨택스트 맵이라고 부른다.

시스템의 전체 구조를 보여준다 따로 규칙은 없고, 시스템의 이해 수준을 보여준다. 즉, 시스템을 더 잘 이해하거나 시간이 지나면서 컨텍스트간 관계가 바뀌면 컨텍스트 맵도 함께 바뀐다.