[DDD START!] 9장. 도메인 모델과 BOUNDED CONTEXT

도메인 모델과 경계

한 도메인은 여러 하위 도메인으로 구분되기 때문에, 한 개의 모델로 여러 하위 도메인을 모두 표현하려다보면 모든 하위 도메인에 맞지 않는 모델을 만들게 된다.

(ex. 주문 - 상품 / 배송 - 상품 / 재고 - 상품) 논리적으로는 같아 보이지만, 실제로 사용하는 방법은 다 다르다

 

하위 도메인마다 같은 용어라도, 의미가 다르고 지칭하는 용어가 다를 수 있기 때문에, 한 개의 모델로 모든 하위 도메인을 표현할 수 없다.

 

여러 하위 도메인의 모델이 섞이기 시작하면 모델의 의미가 약해지고, 요구사항을 모델에 반영하기가 어렵다.

모델은 구분되는 경계를 가지게 되는데 이를 BOUNDED CONTEXT라 한다.

 

BOUNDED CONTEXT

모델의 경계를 결정하며, 한 개의 BOUNDED CONTEXT는 논리적으로 한 개의 모델을 갖는다.

- 카탈로그 컨텍스트와 재고 컨텍스트는 서로 다른 용어를 사용하므로, 컨텍스트를 분리할 수 있다.

 

이상적으로 하위 도메인과 BOUNDED CONTEXT가 일대일 관계를 가지면 좋겠지만, 아직 명확하게 구분되지 않은 경우 두 하위 도메인을

한 BOUNDED CONTEXT에서 구현한다.

 

규모가 작은 기업은 여러 하위 도메인(회원, 카탈로그, 재고 등..)을 하나의 BOUNDED CONTEXT에서 구현.

- 하위 도메인의 모델이 섞이지 않도록 한다.

- 한 개의 BOUNDED CONTEXT에서 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 나눠야 한다.

 

BOUNDED CONTEXT는 구현하는 하위 도메인에 알맞은 모델을 포함한다.

같은 User를 기준으로,

주문 BOUNDED CONTEXT와 회원 BOUNDED CONTEXT가 다르다.

 

BOUNDED CONTEXT의 구현

BOUNDED CONTEXT는 도메인 모델뿐만 아니라 도메인 기능을 사용자에게 제공하는 데 필요한 영역을 모두 포함한다.

 

모든 BOUNDED CONTEXT를 반드시 도메인 주도로 개발할 필요는 없다.

- 도메인 로직의 복잡 여부를 따라...

 

서비스-DAO 구조를 사용하면 도메인 기능이 서비스에 흩어지게 되지만, 도메인 기능 자체가 단순하면, CRUD 방식을 사용해도 코드를 유지보수하는 데

문제가 되지 않는다.

 

한 BOUNDED CONTEXT에서 두 방식을 혼합해서 사용할 수도 있다.

CQRS 패턴

- 상태를 변경하는 명령 기능과 내용을 조회하는 쿼리 기능을 위한 모델을 구분하는 패턴

 

BOUNDED CONTEXT는 서로 다른 구현 기술을 사용할 수 있다.

Spring MVC + JPA/Hibertnate or HBase, MongoDB 등등...

 

BOUNDED CONTEXT간 통합

BOUNDED CONTEXT간 관계

 

BOUNDED CONTEXT는 어떤 식으로든 연결되기 때문에 두 BOUNDED CONTEXT는 다양한 방식으로 관계를 맺는다.

 

하류 컴포넌트인 카탈로그 컨텍스트는 상류 컴포넌트인 추천 컨텍스트가 제공하는 데이터와 기능에 의존.

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

 

상류 컴포넌트 - 서비스 공급자 역할

하류 컴포넌트 - 고객 역할

 

상류 컴포넌트는 보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜 정의

- 추천 시스템은 하류 컴포넌트가 사용할 수 있는 REST API를 제공할 수 있다.

 

상류 팀의 고객인 하류 팀이 다수 존재하면 상류 팀은 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해서,

서비스의 일관성을 유지할 수 있다.

--> 공개 호스트 서비스라고 한다.

 

공개 호스트 서비스의 대표적인 예는 검색 서비스다.

 

각 서비스 별로 검색 기능을 구현하기 보다는 검색을 위한 전용 시스템을 구축하고, 각 서비스를 통합한다.

이 때, 검색 시스템은 상류 컴포넌트가 되고, 블로그 / 카페 등이 하류 컴포넌트가 된다.

 

상류 팀은 각 하류 컴포넌트의 요구사항을 수용하는 단일 API를 공개하고, 하류 팀에서 공개 API를 사용해서 검색 기능을 구현하게 된다.

 

상류 컴포넌트의 서비스는 상류 BOUNDED CONTEXT의 도메인 모델을 따른다.

따라서, 하류 컴포넌트는 상류 서비스의 모델이 자신의 도메인 모델에 영향을 주지 않도록, 완충 지대를 만들어야한다.

--> 안티코럽션 계층

--> 두 BOUNDED CONTEXT간의 모델 변환을 처리, 다른 BOUNDED CONTEXT 모델에 영향을 받지 않고, 나의 도메인을 유지할 수 있다.

 

 

두 BOUNDED CONTEXT가 같은 모델을 공유하는 경우도 있다.

운영자를 위한 주문 관리 도구 개발 팀과

고객을 위한 주문 서비스 개발하는 팀

2개의 팀이 있을 때, 주문을 표현하는 모델을 공유함으로 중복 개발을 막을 수 있고, 이를 공유 커널(SHARED KERNEL)이라고 부른다.

--> 장점 : 중복을 줄일 수 있다.

 

독립 방식(SEPARATE WAY)

- 통합하지 않고, 서로 독립적으로 모델을 발전시킨다.

쇼핑몰, ERP 솔루션

 

컨텍스트 맵

개별 BOUNDED CONTEXT에 매몰되면 전체를 보지 못한다.

나무만 보고 숲을 보지 못하는 상황을 방지하려면, 전체 비즈니스를 조망할 수 있는 지도가 필요한데, 그것이 바로 컨텍스트 맵이다.