도메인 모델과 경계

 

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

 

이유는 하위 도메인마다 사용하는 용어와 의미가 다르기 때문인데,

 

예를 들어 상품이라는 모델이 있다. 

 

카탈로그에서의 상품, 재고 관리에서의 상품, 주문에서의 상품, 배송에서의 상품

 

하위 도메인에서 상품은 이름만 갖지 실제 의미하는 것이 다르다. 

 

카탈로그에서는 상품의 정보가 주된 목적이라면, 재고 관리에서는 추적을 위한 정보, 주문에서는 장바구니에 담겨있는 상품들과 가격 정보.. 등등

 

실제 하위 도메인에서 바라보는 상품은 그 개수가 하나일 수도 여러 개일 수도 있다.

 

따라서 도메인을 두고 고민을 할 때 다음 내용을 떠올리자.

 

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

 

따라서 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.!

 

각 모델은 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야 한다. 

 

만약 이러한 경계가 무너지기 시작하면 새롭게 모델을 만든 의미가 희석될 것이다.  또한 하위 도메인 별로 추가되는 요구사항을 반영하기가 어려워질 수 있다.

 

모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다.

 

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

 

 

바운디드 컨텍스트는 모델의 경계를 결정한다. 그렇기 때문에 논리적으로 한 개의 모델을 갖는다. 

바운디드 컨텍스트를 쉽게 구분하는 것은 바로 용어이다. 

 

위 예시에서 카탈로그의 콘텍스트와 재고 콘텍스트는 서로 다른 용어를 사용하기 때문에 이 용어를 기준으로 콘텍스트를 분리할 수 있다. 

 

이러한 하위 도메인과 바운디드 컨텍스트가 일대일 관계를 가지지 않을 수도 있다.

 

예를 들어 주문 하위 도메인이라도 주문을 처리하는 팀과 복잡한 결제 금액 계산 로직을 구현하는 팀이 따로 있다고 해보자.  이 경우 주문 하위 도메인에는 두 개의 바운디드 콘텍스트가 존재하게 된다.

 

1. 주문

2. 결제 금액 계산

 

혹은 용어를 명확하게 구분하지 못해 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.

 

예를 들면 카탈로그와 재고 관리이다.

 

 

잠시 정리가 필요할 것 같다. 일반적으로 DDD는 MSA에 적합한 아키텍쳐로 보인다.

 

각 도메인마다 별도의 애플리케이션으로 제공하여 서로 바운디드 컨텍스트가 다르기 때문에 다른 모델을 구축해서 진행하는 것이 매우 합리적으로 보인다.

 

하지만 규모가 작은 기업에서는 하나의 어플리케이션으로 하나의 서비스를 제공하는 경우가 많다. 

 

이 경우에는 어떻게 해야할 까? 

 

예를 들어 쇼핑몰 서비스를 제공한다. 이는 하나의 시스템에서 회원, 카탈로그, 재고, 구매, 결제와 관련된 모든 기능을 제공한다. 

 

즉 여러 하위 도메인을 한 개의 바운디드 콘텍스트에서 구현한다. 

 

즉 쇼핑 바운디드 컨텍스트콘텍스트 내부에 주문, 재고, 결제.. 바운디드 콘텍스트들이 포함되어 있는 형태다. 

 

이 경우 다음을 조심해야한다. 쇼핑 바운디드 콘텍스트라는 단일 모델로 서비스를 구축하고 싶을 수 있다.

하지만 이러한 모델을 구축하게 되면 하위 도메인을 확장하기가 어려워질 수 있다.  이는 서비스 경쟁력 하락을 의미한다. 

 

비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 하며, 이로써 하위 도메인을 위한 모델이 뒤 섞이지 않고 바운디드 컨텍스를 각각 갖고 있는 듯한 효과를 낼 수 있다.

 

 

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

간단한 경우 DAO와 밸류객체를 이용해 기능을 구현해도 된다.

 

한 바운디드 콘텍스트에서 혼합하여 사용하고 싶다면 CQRS 패턴을 고려해 보자.

 

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

 

 

이러한 바운디드 콘텍스트를 나누어 개발을 하다 보면 인프라스트럭쳐영역에 다양한 기술을 적용할 수 있다.

 

예를 들어 표현 영역에는 스프링 MVC를 리포지터리 기술에는 JPA/HIBERNATE를 사용하는 바운디드 콘텍스트,

Netty를 이용해서 Rest API를 제공하고 마이바티스를 리포지터리 구현 기술로 사용하는 바운디드 콘텍스트가 존재할 수 있다.

https://netty.io/

Netty: Home

 

지금까지 바운디드 콘텍스트를 나누었다면 통합해야 하는 경우도 있다.

 

 

이는 하위 도메인 바운디드 콘텍스트에서 추가되는 요구사항에 따라 생성되는 바운디드 콘텍스트가 존재하는 경우를 예를 든다. 

 

 

마치 쿠팡에서 배민에서 상품을 쇼핑할 때 하위에 추천 상품이나 해당 상품을 구매한 사람이 확인했던 물품을 추천하는 바운디드 컨텍스트가 있을 수 있다. 

 

이는 상품을 바라보는 용어가 다르기에 별도의 바운디드 콘텍스트지만 기능은 하나로 제공하여야 한다. 

 

이 경우 간접적인 통합을 위해 메시지 큐를 사용할 수 있다.

 

사용자가 확인한 상품 정보를 메시지 큐에 담아 추천 바운더리 콘텍스트에서 가져가는 방법과

역으로 추천 바운디드 콘텍스트는 메시지를 읽어와 추천을 계산한다. 

 

이것은 두 바운디드 콘텍스트가 사용할 메시지의 데이터 구조를 맞춰야 함을 의미한다. API에 대한 형식을 정한다.

 

두 바운디드 콘텍스트를 개발하는 팀은 메시징 큐에 담을 데이터의 구조를 협의하게 된다. 

그 큐를 누가 제공하느냐에 따라 데이터 구조가 결정된다. 

 

만약 카탈로그 도메인에서 제공한다면 미시지 큐에 카탈로그와 관련된 메시지를 저장하게 되고 다른 바운디드 콘텍스트는 해당 메시지를 수신하기 위해 컨버팅 하는 과정이 필요하게 될 것이다.

 

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

이런 마이크로서비스의 특징은 바운디드 콘텍스트와 잘 어울린다. 각 바운디드 컨텍스트는 모델의 경계를 형성하는데 바운디드 컨텍스트를 마이크로서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리되기 때문이다.

 

자꾸 공부를 하면서 MSA가 생각났던 이유 중 하나이다.

 

그렇다면 바운디드 컨텍스트 간 관계를 살펴보자.

 

API 스펙에 영향을 미칠 때 본인이 속한 팀이 아닌 사용하는 팀에서 아우성이 들릴 수 있다.

이 경우는 고객/공급자 역할로 구분된 바운디드 콘텍스트의 관계이다.

 

공급자 역할의 바운디드 콘텍스트에서 API 스펙을 마음대로 변경하면 고객 역할의 바운드디 콘텍스트를 개발하는 팀은 변경된 API를 맞추기 위해 노력해야 한다. 

이러한 관계는 개발 생산성을 하락시킨다.

 

공급자 컴포넌트는 고객 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개한다. 이를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있고 이를 공개 호스트 서비스 ( Open Host Service)라고 한다.

 

이러한 공개 호스트 서비스의 예시로는 검색이다.

 

각 서비스 별로 검색 기능을 구현하는 것보다는 검색을 위한 전용 시스템을 구축하고 검색 시스템을 각 서비스와 통합하는 것이 더 효율적이다. 

 

이때 검색 시스템은 공급자가 되고 이를 이용하는 서비스는 고객이 될 것이다.

이때 고객 역할의 서비스들은 공급자의 도메인 모델이 자신의 도메인 모델에 영향을 주지 않도록 보호해야 하는 완충 지대가 필요하다.

 

이러한 완중 지대를 도메인 영역의 인터페이스를 구현한 구현체로 볼 수 있고 해당 영역을 Anticorruption Layer이라 하고 이 구현체가 안티코럽션 계층역할을 한다.

 

만약 서로 다른 바운디드 콘텍스트들이 같은 모델을 공유할 수 있다. 이러한 공유 모델을 Shared Kernel이라고 부른다.

 

 

마지막은 독립 방식 ( Separate Way)로 통합하지 않는 것이다.

 

독립 방식으로 서로 통합하지 않기 때문에 독립적으로 모델을 발전시킨다.

만약 통합이 필요하다면 수동으로 진행해야 한다. 

 

만약 규모가 커질수록 수동 통합에는 한계가 있으므로 두 바운디드 콘텍스트를 통합하기 위해 별도의 통합 시스템을 구축해야 한다.