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

Y_Sevin·2023년 9월 9일

DDD 도메인 주도 개발이란?

목록 보기

9/10

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

논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우
카탈로그에서 상품(상품 정보 위주) ≠ 재고 관리 상품(실존하는 개별 객체를 추적하는 용도)

ex) 시스템을 사용하는 사람

회원 도메인 → 회원, 주문 도메인 → 주문자, 배송 도메인 → 보내는 사람

이렇듯 하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있음
때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수 없음
여러 하위 도메인의 모델이 섞이면 모델의 의미가 약해질 뿐만 아니라 여러 도메인의 모델이 서로 얽히기 때문에 각 하위 도메인별로 다르게 발전하는 요구사항을 모델에 반영하기 어려워짐

--> 따라서 모델은 특정 컨텍스트 하에서 완전한 의미를 가진다. 이러한 컨텍스트를 바운디드 컨텍스트라고 부름

모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐
바운디드 컨텍스트는 각자 구현하는 하위 도메인에 맞는 모델을 갖음
-> 하위 도메인(1) : 바운디드 컨텍스트(1) 이렇게 구상하는것이 이상적이지만 현실은 팀 조직 구조에 따라 결정
실제로 사용자에게 기능을 제공하는 물리적 시스템 도메인 모델은 이 바운디드 컨텍스트 안에서 도메인을 구현
한 개의 바운디드 컨텍스트에 여러 하위 도메인이 포함되는 경우, 하위 도메인마다 구분되는 패키지를 갖도록 구현하여 하위 도메인의 모델이 섞이지 않도록 함
- 단일 모델로 만들면 확장이 어려워자고 서비스 경쟁력을 떨어트림

바운디드 컨텍스트는 도메인 모델 뿐만 아니라 도메인 기능을 사용자에게 제공하는 데 필요한 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함함
도메인 모델의 데이터 구조가 변경되면 DB 테이블 스키마도 함께 변경해야 하므로 테이블도 포함

모든 바운디드 컨텍스트를 반드시 DDD로 개발할 필요는 없음
한 바운디드 컨테스트에서 두 방식을 혼합해서 사용 가능 → 대표적으로 CQRS 상태 변경 : DDD, 조회 기능 : 서비스-DAO

온라인 쇼핑 사이트에서 매출 증대를 위해 카탈로그 하위 도메인에 개인하 추천 기능을 도입하기로 했다고 가정했을 때, 카탈로그 하위 도메인에는 기존 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 생김

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

바운디드 컨텍스트 간 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계이다. REST API가 대표적임
- 이 관계에서 API를 사용하는 바운디드 컨텍스트는 API를 제공하는 바운디드 컨텍스트에 의존하게 됨

상류 컴포넌트

일종의 서비스 공급자 역할
보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개함
하류 컴포넌트가 다수 존재할 때 여러 하류 컴포넌트의 요구사항을 수용할 수 있는 API를 만들고, 이를 서비스 형태로 하류 컴포넌트에게 제공을 하며 서비스의 일관성을 유지함 (ex. 공개 호스트 서비스 - ex. 검색)