[DDD] chapter 9

Chapter 9

9.1 도메인 모델과 경계

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

 

카탈로그에서 상품, 재고 관리에서 상품, 주문에서 상품, 배송에서 상품은 이름만 같지 실제로 의미하는 것이 다르다. 카탈로그에서의 상품은 상품 이미지와같은 상품 정보가 위주라면, 재고 관리에서는 실존하는 개별 객체를 추적하기 위한 목적으로 개별 객체를 추적하기 위한 목적으로 상품을 사용한다. 즉, 카탈로그에서는 물리적으로 한 개인 상품이 재고 관리에서는 여러 개 존재할 수 있다.

 

논리적으로 같은 존재처럼 보이지만, 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다.카탈로그  도메인에서의 상품이 검색 모데인에서는 문서로 물리기도 한다. (이러면 너무 복잡해질 것 같은데... ㅠㅠ)

 

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

 

하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야한다. 각 모델은 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야 한다.

 

모델은 특정한 컨텍스트 하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 바운디드 컨텍스트 라고 부른다.

 

9.2 바운디드 컨텍스트

바운디드 컨텍스트

• 모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.
• 바운디드 컨텍스트는 용어를 기준으로 구분한다.
• 예시
  • 카탈로그 컨텍스트와 재고 컨텍스트는 서로 다른 용어를 사용하므로 이 용어를 기준으로 컨텍스트를 분리할 수 있다.
• 실제로 사용자에게 기능을 제공하는 물리적 시스템이다.
  • 도메인 모델은 이 바운디드 컨텍스트 안에서 도메인을 구현한다.

9.3 바운디드 컨텍스트 구현

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

---

---

(개인적인 생각으로 context는 그냥 어어엄청 높은 수준의 도메인의 개념이 아닌가 싶다...)

 

모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다. 상품의 리뷰는 복잡한 도메인 로직을 갖지 않기 때문에 CRUD 방식으로 구현해도 된다. (하나의 기능을 컨텍스트로 묶는건가... 이러면 협업이 매우 편해질 것 같다. MSA의 단일 서버 느낌인 것 같다.)

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

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

 

만약 사용자가 카탈로그 바운디드 컨텍스트에 추천 제품 목록을 요청하면 카탈로그 바운디드 컨텍스트는 추천 바운디드 컨텍스트로부터 추천 정보를 읽어와 추천 제품 목록을 제공한다.

 

카탈로그 시스템은 추천 시스템으로 부터 추천 데이터를 받아오지만, 카탈로그 시스템에서는 추천의 도메인 모델을 사용하기 보다는 카탈로그 도메인 모델을 사용해 추천 상품을 표현해야 한다.

 

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

 

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

 

여기서 외부 추천 시스템에 관련된 내용이 나오는데,  추천 상품을 구현하는 시스템을 외부에서 구현하고 해당 시스템의 결과를  Rest API로 호출하는 방법이 나온다... (그렇게 되면 Rest API가 아닌 단일 서버는 어떻게 해야하나...?)

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

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

 

상류 하류의 관계

한 쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계이다.

• 하류 컴포넌트는 상류 컴포넌트가 제공하는 데이터에 의존한다.
• 상류 컴포넌트는 일종의 서비스 공급자 같은 역할을 한다.
• 상류 컴포넌트가 변경되면 하류 컴포너트 까지 변경해야한다는 단점이 있다.

공유 커널 구조

• 중복을 줄여준다.
• 하나의 컴포넌트에서 모델을 변경할 수 없으며, 변경하게 되면 복잡한 절차를 따르게 된다.

독립 방식 구조

• 수동으로 통합을 이루는 구조이다.
• 규모가 커질수록 사용하기 불편하다는 단점이 있다.
  • 따라서 별도의 시스템을 제작해 주어야한다.

9.6 컨텍스트 맵

---

---

개별 바운디드 컨텍스트에 메몰되지 않게 전체적인 시각을 가지기에 용이하다.