도메인 주도 개발 시작하기 - 9장

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

 

9.1

처음 도메인 모델을 만들 때 빠지기 쉬운 함정이 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것이다.

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

논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다.

하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.

이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서 바운디드 컨텍스트라고 부른다.

 

9.2

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

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

API바운디드 컨텍스트는 기업의 팀 조직 구조에 따라 결정되기도 한다.

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

물리적인 바운디드 컨텍스트가 한 개이더라도 내부적으로 패키지를 활용해서 논리적으로 바운디드 컨텍스트를 만든다.

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

 

9.3

바운디드 컨텍스트가 도메인 모델만 포함하는 것은 아니다. 바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는 데 필요한 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함한다.

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

한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수도 있다. CQRS패턴

바운디드 컨텍스트가 반드시 사용자에게 보여지는 UI를 가지고 있는 것은 아니다.

 

9.4

기존 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 생긴다.

카탈로그와 추천 바운디드 컨텍스트 간 통합이 필요한 기능은 다음과 같다.

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

카탈로그 컨텍스트와 추천 컨텍스트의 도메인 모델은 서로 다르다.

카탈로그의 모델을 기반으로 하는 도메인 서비스를 이용해서 상품 추천 기능을 표현해야 한다.

도메인 서비스를 구현한 클래스는 인프라스트럭처 영역에 위치한다.

외부 연동을 위한 도메인 서비스 구현 클래스는 도메인 모델과 외부 시스템 간의 모델 변환을 처리한다.

REST API로부터 데이터를 읽어와 카탈로그 도메인에 맞는 상품 모델을 변환한다.

두 모델 간의 변환 과정이 복잡하면 변환 처리를 위한 별도 클래스를 만들고 이 클래스에서 변환을 처리해도 된다.

REST API를 호출하는 것은 두 바운디드 컨텍스트를 직접 통합하는 방법과 간접적으로 통합하는 방법이 있다.

대표적인 간접 통합 방식은 메시지 큐를 사용하는 것이다.

어떤 도메인 관점에서 모델을 사용하느냐에 따라 두 바운디드 컨텍스트의 구현 코드가 달라지게 된다.

두 바운디드 컨텍스트를 개발하는 팀은 메시징 큐에 담을 데이터의 구조를 협의하게 되는데 그 큐를 누가 제공하느냐에 따라 데이터 구조가 결정된다.

큐로 인해 비동기로 추천 시스템에 데이터를 전달하는 것을 제외하면 추천 시스템이 제공하는 REST API를 사용해서 데이터를 전달하는 것과 차이가 없다.

 

9.5

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

추천 시스템이 제공하는 REST API 인터페이스가 바뀌면 카탈로그 시스템의 코드도 바뀌게 된다.

상류 팀과 하류 팀은 개발자 계획을 서로 공유하고 일정을 협의해야 한다.

프로토콜 버퍼(grpc?)

API를 만들고 이를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있다. - 공개 호스트 서비스

상류 서비스의 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해주는 완충 지대를 만들어야한다.

두 바운드 컨텍스트가 같은 모델을 공유하는 경우도 있다.

두 팀이 공유하는 모델을 공유 커널이라고 부른다.

두 팀이 밀접한 관계를 형성할 수 없다면 공유 커널을 사용할 때의 장점보다 지연,정체되는 문제가 더 크다.

독립방식 - 서로 통합하지 않는다.독립 방식에서 두 바운디드 컨텍스트 간의 통합은 수동으로 이루어진다.

수동으로 통합하는 방식이 나쁜 것은 아니지만, 한계가 있어서 차후 통합해야할 수도 있다.

 

9.6

개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못할 때가 있다.

컨텍스트간 관계를 나타낸 지도 - 컨텍스트 맵

어떤 바운디드 컨텍스트에 집중할지 파악하는 데 도움을 준다.

컨텍스트 맵을 그리는 규칙은 따로 없다.