도메인 주도 개발 시작하기 : 9장 도메인 모델과 바운디드 컨텍스트

9.1 도메인 모델과 경계

• 처음 도메인 모델을 만들 때 도메인을 완벽하게 표현하는 단일 모델로 만들면 모든 하위 도메인에 맞지 않는 모델을 만들게 된다.
  • 예시 > 카탈로그에서 상품, 재고 관리에서 상품, 주문에서 상품, 배송에서 상품은 이름만 같지 실제로 의미하는 것이 다르다.
    • 카탈로그에서 상품은 이미지, 상품명, 상품 가격, 옵션 목록, 상세 설명과 같은 상품 정보 위주
    • 재고관리에서는 실존하는 개별 객체를 추적하기 위한 목적
    • 카탈로그에서는 물리적으로 한 개인 상품이 재고 관리에서는 여러 개 존재할 수 있다.
  • 논리적으로 같더라도 하위 도메인에 따라 다른 용어를 사용하는 경우

    • 카탈로그 도메인에서의 상품이 검색 도메인에서는 문서로 불리기도 한다.

      

• 따라서 하위 도메인마다 모델을 만들어야한다.
  • 명시적으로 구분되는 경계를 가져서 섞이지 않도록 해야한다.
• 모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖는다.
  • 바운디드 컨텍스트 : 구분되는 경계를 갖는 컨텍스트

9.2 바운디드 컨텍스트

• 모델의 경계를 결정

• 용어 기준으로 구분

• 실제로 사용자에게 기능을 제공하는 물리적 시스템

• 바운디드 컨텍스트는 기업의 팀 조직 구조에 따라 결정되기도 한다.

  • 예시 > 주문 하위 도메인이라도 주문을 처리하는 팀과 결제 금액 계산 로직을 구현하는 팀이 따로 있는 경우

    • 용어 구분을 명확하게 구분하지 못해 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현할 수도 있고, 분리할 수도 있다.

      

  • 규모가 작은 기업은 전체 시스템을 한 개 팀에서 구현할 때도 있다.
    • 소규모 쇼핑몰은 하나의 시스템에서 회원, 카탈로그, 재고, 구매, 결제와 관련된 기능 제공
    • 여러 하위 도메인을 한 개의 바운디드 컨텍스트에서 구현
      • 하위 도메인 모델이 섞이지 않도록 주의
        • 전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠지지 말자.
          • 도메인 모델이 개별 하위 도메인을 제대로 반영하지 못해서 하위 도메인별로 기능을 확장하기 어렵게 된다.
      • 하위 도메인마다 구분되는 패키지를 갖도록 구현

        • 하위 도메인을 위한 모델이 서로 뒤섞이지 않고 하위 도메인마다 바운디드 컨텍스트를 갖는 효과를 낼 수 있다.

          

9.3 바운디드 컨텍스트 구현

• 바운디드 컨텍스트는 도메인, 응용 서비스, 인프라스트럭처, 표현 영역 모두 포함
• 간단한 기능이면 도메인 주도로 개발할 필요는 없다.
• 바운디드 컨텍스트에 CQRS를 적용한 예시
• 각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수도 있다.
  • 리포지터리 구현 기술 : JPA / Netty / Mybatis 등
  • DB : RDBMS, NoSQL 등
• 바운디드 컨텍스트가 반드시 사용자에게 보여지는 UI를 가지고 있는 것은 아니다.
  • JSON 응답도 가능
• 각 바운디드 컨텍스트는 UI 서버를 통해 간접적으로 브라우저와 통신 가능
  • UI 서버는 파사드 역할

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

• 바운디드 컨텍스트를 통합하는 예시

  • 온라인 쇼핑 사이트에서 카탈로그 하위 도메인에 개인화 추천 기능을 도입하기로 했다고 하자.

    

  • 카탈로그와 추천 바운디드 컨텍스트 간 통합이 필요한 기능

    • 사용자가 제품 상세 페이지를 볼 때 보고 있는 상품과 유사한 상품 목록을 하단에 보여준다.

      • 카탈로그는 제품을 중심으로 도메인 모델을 구현, 추천은 추천 연산을 위한 모델 구현

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

        

        • 추천 시스템에서 가져온 상품 id 값을 이용해 카탈로그 모델로 변환한다.

  • 직접 통합 방식 : Rest API

  • 간접 통합 방식 : 메세지큐

    

    • 어떤 도메인 관점에서 모델을 사용하느냐에 따라 메시지 데이터가 달라진다.

      • 메시지 큐를 누가 제공하느냐에 따라 결정

        

• MSA의 서비스를 바운디드 컨텍스트 별로 분리한다.

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

• 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계가 대표적

  • Rest API, protocol buffer

  • API 규격이 변경되는 경우 상호 협력이 필수

    • 공개 호스트 서비스

      • 상류 팀은 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개
      • 예시 > 검색

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

          

      • 공개 호스트 서비스가 내 도메인 모델을 침범하지 않도록 인터페이스로 정의

• 공유 커널

  • 두 바운디드 컨텍스트가 같은 모델을 공유하는 경우
    • 중복을 줄여준다.

• 독립 방식 관계

  • 서로 통합하지 않는 방식
  • 통합은 수동으로 이루어진다.
    • 통합하기 위해 별도의 시스템을 만들어야 할 수도 있다.

9.6 컨텍스트 맵

• 전체 비즈니스를 조망할 수 있는 지도

• OHS : 오픈 호스트 서비스
• ACL : 안티코럽션 계층