TIL

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

9.1 도메인 모델과 경계

한 도메인은 여로 하위 도메인으로 구분되기에 여러 하위 도메인을 한 모델로 모두 표현하려고 하면 하위 도메인에 맞지 않는 모델을 만들게 된다.
- 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다.
- ex) ‘카탈로그’에서의 ‘상품’, ‘재고 관리’에서의 ‘상품’, ‘주문’에서의 ‘상품’은 이름만 같지 실제 의미하는 것은 다르다.
모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖는데 이 경계를 갖는 컨텍스트를 DDD에서 바운디드 컨텍스트라고 부른다.
- 하위 도메인의 모델이 섞이기 시작하면 모델의 의미가 약해진다.
- 여러 도메인의 모델이 서로 얽히게 되면 각 하위 도메인별로 다르게 발전하는 요구사항을 모델에 반영하기 어려워진다.

9.2 바운디드 컨텍스트

바운디드 컨텍스트와 하위 도메인이 일대일 관계를 가지면 좋겠지만 기업의 팀 조직 구조에 따라 결정되기도 한다.
- ex) 주문 하위 도메인이라도 주문 팀과 복잡한 결제 처리 팀이 따로 있다면 주문 컨텍스트와 결제 컨텍스트가 존재하게 된다.
- 용어를 명확히 구분하지 못해 두 하위 도메인을 한 컨텍스트 안에서 구현하기도 한다.
- 규모가 작은 기업에선 전체 시스템을 한 개 팀에서 구현할 때도 있다.
여러 하위 도메인을 한 바운디드 컨텍스트에서 구현할 때 하위 도메인의 모델이 섞이지 않도록 주의해야 한다.
- 한 프로젝트에 각 하위 도메인 모델이 위치하면 전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠지기 쉽다.
- 단일 모델을 만들어버리면 하위 도메인별로 기능을 확장하기 어려워진다.
- 하위 도메인마다 구분되는 패키지를 갖도록 구현하자.

9.3 바운디드 컨텍스트 구현

바운디드 컨텍스트는 도메인 모델 뿐만 아니라 표현, 응용, 인프라 영역을 모두 포함한다.
모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다.
- 복잡하지 않은 도메인 로직을 가지고 있다면 CRUD 방식으로 구현해도 된다. (DAO와 데이터 중심의 밸류 객체를 이용)
한 바운디드 컨텍스트에서 여러 방식을 혼합해서 사용할 수도 있다.
- CQRS 패턴으로 상태 변경과 관련된 기능은 도메인 모델 기반으로 구현하고, 조회 기능은 서비스-DAO를 이용해서 구현할 수도 있다.
각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수도 있다.

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

두 바운디드 컨텍스트가 통합되어 서비스를 제공해야 하는 경우가 있다.
REST API를 호출하여 두 컨텍스트를 직접 통합할 수 있다.
메시지 큐를 사용해 두 컨텍스트를 간접적으로 통합할 수도 있다.
‘카탈로그 컨텍스트’와 ‘추천 컨텍스트’가 통합하는 예제를 살펴 보자.
- ‘사용자가 제품 상세 페이지를 볼 때 유사한 상품 목록을 하단에 보여준다.’라는 요구 사항
- 사용자가 마탈로그 바운디드 컨텍스트에 추천 제품 목록을 요청하면 카탈로그 컨텍스트는 추천 컨텍스트로부터 추천 정보를 읽어 와야 한다.
- 카탈로그는 제품 중심의 도메인 모델, 추천은 추천 연산을 위한 모델을 구현

REST API를 통한 컨텍스트 통합

카탈로그 컨텍스트 내에 있는 상품 추천 기능을 표현하는 도메인 서비스

  public interface ProductRecommendationService {
  	List<Product> getRecommendationsOf(ProductId id);
  }

위 도메인 서비스를 구현한 클래스는 인프라 영역에 위치하여 외부 시스템(추천 바운디드 컨텍스트)과의 연동을 처리한다.

  public class RecSystemClient implements ProductRecommendationService {
  	private final ProductRepository productRepository;
  	private final ExternalRecClient externalRecClient;
    
  	@Ovveride
  	public List<Product> getRecommendatonsOf(ProductId id) {
  		List<RecommendatioinItem> items = externalRecClient.getRecs(id.getValue());
  		return toProducts(items);
  	}
    
  	// ...
  }

RecommenationItem은 추천 시스템의 모델을 따르는 객체이다.
외부 시스템으로부터 얻어온 데이터를 카탈로그 도메인에 맞는 상품 모델로 변환하는 책임도 가지고 있다.

메시지 큐를 통한 컨텍스트 통합

추천 시스템은 사용자가 조회한 상품 이력이나 구매 이력 같은 사용자 활동을 메시지 시스템을 통해 얻게 된다.
카탈로그 바운디드 컨텍스트는 추천 시스템이 필요로 하는 사용자 활동 이력을 메시지 큐에 추가한다.
- 비동기로 처리하기에 추천 바운디드 컨텍스트가 메시지를 처리할 때까지 기다리지 않아도 된다.
추천 바운디드 컨텍스트는 큐에서 메시지를 읽어 추천을 계산하는데 사용한다.
두 컨텍스트는 사용할 메시지의 데이터 구조를 통일시킬 필요가 있다.
- 메시지를 누가 제공하느냐에 따라 데이터 구조가 결정되는데 카탈로그 시스템에서 큐를 제공한다면 메시지 내용은 카탈로그 도메인을 따르게 된다.

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

두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺는다.
- REST API, 메시지 큐 등
REST API로 통신한다고 했을 때 API를 사용하는 컨텍스트는 하류 컴포넌트, API를 제공하는 컨텍스트는 상류 컴포넌트라고 부르기도 한다.
- 하류 컴포넌트가 상류 컴포넌트에 의존하게 된다.
- 상류 컴포넌트가 API를 변경하면 하류 컴포넌트도 추가적인 수정 작업이 필요하다.
- 상류 팀과 하류 팀은 계발 계획을 서로 공유하고 일정을 협의해야 한다.
- 상류 컴포넌트가 제공하는 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따르기에 하류 컴포넌트에선 상류 서비스 모델이 자신의 도메인 모델에 영향을 주지 않도록 해야 한다.
두 바운디드 컨텍스트가 같은 모델을 공유할 때도 있는데 이 공유 보델을 공유 커널이라 부른다.
- 공유 커널의 장점은 중복을 줄여준다는 것이다.
- 두 팀이 공유하는 모델이기에 임의로 모델을 변경하면 안 된다.
- 공유 모델을 사용하는 두 팀은 밀접한 관계를 형성할 수밖에 없기에 개발이 지연되고 정체되는 문제가 생기기도 한다.
두 바운디드 컨텍스트가 통합하지 않는 독립 방식도 존재한다.
- 한 외부 시스템이 통합을 지원하지 않는 경우
- 두 컨텍스트 간 통합은 수동으로 이루어진다.
- ex) 쇼핑몰 운영자가 수동으로 쇼핑몰의 판매 정보를 보고 ERP 시스템에 입력
- 규모가 커질수록 수동 통합에는 한계가 있다.
- 술루션으로는 두 바운디드 컨텍스트를 통합해 주는 별도의 시스템을 만들어야 할 수도 있다.

9.6 컨텍스트 맵

컨텍스트 맵이란 바운디드 컨텍스트 간의 관계를 표시한 지도이다.
- 개별 컨텍스트에 매몰되면 전체를 보지 못할 때가 많기에 전체 비즈니스를 조망할 수 있는 지도가 필요하다.
컨텍스트 맵을 그리는 규칙은 따로 없다.
- 간단한 도형과 선을 이요해 관계를 이해할 수 있는 수준에서 그리면 된다.