Chapter 9: 도메인 모델과 경계

💡 책에서 기억하고 싶은 내용

도메인 모델과 경계

• 하위 도메인마다 사용하는 용어와 의미가 다르다

• 모델을 특정한 context(문맥) 하에서 완전한 의미를 갖는다

  • 이렇게 구분되는 경계를 갖는 context를 DDD에서는 바운디드 컨텍스트 라고 부른다

바운디드 컨텍스트

• 바운디드 컨텍스트는 모델의 경계를 결정하며, 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다

• 바운디드 컨텍스트는 용어를 기준으로 구분한다

  • ex) 카탈로그 컨텍스트와 재고 컨텍스트는 서로 다른 용어를 사용하므로 이 용어를 기준으로 컨텍스트를 분리할 수 있다

• 바운디드 컨텍스트는 실제로 사용자에게 기능을 제공하는 물리적 시스템으로, 도메인 모델은 이 바운디드 컨텍스트 안에서 도메인을 구현 한다

• 하위 도메인과 바운디드 컨텍스트가 1:1 관계 를 가지면 좋겠지만, 현실은 그렇지 않을 때가 많다

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

• 여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 주의할 점

  • 하위 도메인의 모델이 섞이지 않도록 하는 것!

    • 비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도, 하위 도메인마다 구분되는 패키지를 갖도록 구현해야 하며

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

• 물리적인 바운디드 컨텍스트가 한 개이더라도, 내부적으로 패키지를 활용해서 논리적으로 바운디드 컨텍스트를 만든다!

• 바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에, 바운디드 컨텍스트는 구현하는 하위 도메인에 알맞은 모델을 갖는다

  • ex)

    • 같은 사용자라 하더라도 주문 바운디드 컨텍스트와 회원 바운디드 컨텍스트가 갖는 모델이 달라진다

      • 회원의 Member는 애그리거트 루트이지만 주문의 Orderer는 밸류가 된다

    • 같은 상품이라도 카탈로그 바운디드 컨텍스트의 Product와 재고 바운디드 컨텍스트의 Product는 각 컨텍스에 맞는 모델을 갖는다

      • 카탈로그의 Product는 상품이 속할 Category와 연관을 갖지만, 재고의 Product는 카탈로그의 Category와 연관을 맺지 않는다

바운디드 컨텍스트 구현

• 바운디드 컨텍스트가 도메인 모델만 포함하는 것은 아니다

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

  • 도메인 모델의 데이터 구조가 바뀌면 DB 테이블 스키마도 함께 변경해야 하므로 테이블도 바운디드 컨텍스트에 포함된다

• 바운디드 컨텍스트는 도메인 기능 을 제공하는 데 필요한 모든 요소를 포함한다

• 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없다

  • 상품의 리뷰는 복잡한 도메인 로직을 갖지 않기 때문에 CRUD 방식으로 구현해도 된다

    • 즉, DAO와 데이터 중심의 밸류 객체를 이용해서 리뷰 기능을 구현해도 기능을 유지보수 하는데 큰 문제가 없다

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

• 한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수도 있다

  • ex) CQRS (Command Query Responsibility Segregration)

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

    • 상태 변경과 관련된 기능 → 도메인 모델 기반으로 구현

    • 조회 기능 → 서비스-DAO 를 이용해서 구현

• 각 바운디드 컨텍스트는 UI 서버를 통해 간접적으로 브라우저와 통신할 수도 있다

  • 이 구조에서 UI 서버는 각 바운디드 컨텍스트를 위한 파사드 역할을 수행한다

    • 브라우저가 UI 서버에 요청을 보내면, UI 서버는 카탈로그와 리뷰 바운디드 컨텍스트로부터 필요한 정보를 읽어와 조합한 뒤 브라우저에 응답을 제공한다

바운디드 컨텍스트 간 통합

• 외부 연동을 위한 도메인 서비스 구현 클래스는 도메인 모델 과 외부 시스템 간의 모델 변환 을 처리한다

  • 모델 간 변환이 복잡하면, 별도 변환기 를 둔다

• REST API를 두어 두 바운디드 컨텍스트를 직접 통합할 수도 있지만, 메시지 큐 를 사용하여 간접적으로 통합할 수도 있다

  • ex)

    • 추천 시스템은 사용자가 조회한 상품 이력이나 구매 이력과 같은 사용자 활동 이력을 필요로 하는데, 이 내역을 전달할 때 메시지 큐 를 사용할 수 있다

      • 메시지 큐는 비동기 로 메시지를 처리하기 때문에 카탈로그 바운디드 컨텍스트는 메시지를 큐에 추가한 뒤에, 추천 바운디드 컨텍스트가 메시지를 처리할 때 까지 기다리지 않고 이어서 자신의 처리를 계쏙한다

    • 각각의 바운디드 컨텍스트 담당 팀은 주고 받을 데이터 형식 에 대해 협의해야 한다

      • ex)

        • 카탈로그 도메인 모델을 기준으로 메시지를 전송하면, 추천 시스템은 자신의 모델에 맞게 메시지를 변환해서 처리해야 한다

      • 두 바운디드 컨텍스트를 개발하는 팀은 메시징 큐에 담을 데이터 구조 를 협의하게 되는데, 그 큐를 누가 제공하느냐 에 따라 데이터 구조가 결정된다

        • 제공하는 쪽의 도메인을 따르게 된다

        • 이 방식은 한쪽에서 메시지를 publish하고, 다른 쪽에서 메시지를 subscribe 하는 Publish - Subscribe 모델을 따른다

마이크로서비스와 바운디드 컨텍스트

• 개별 서비스를 독립된 프로세스로 실행하고, 각 서비스가 REST API나 메시징을 통해서 통신하는 마이크로서비스는 바운디드 컨텍스트 와 잘 어울린다

• 각 바운디드 컨텍스트는 모델의 경계 를 형성하는데, 바운디드 컨텍스트를 마이크로서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리 된다

  • 코드로 생각하면 마이크로서비스마다 프로젝트를 생성하므로, 바운디드 컨텍스트마다 프로젝트를 만들게 된다

    • 이것은 코드 수준에서 모델을 분리하여 두 바운디드 컨텍스트의 모델이 섞이지 않도록 해준다

• 별도 프로세스로 개발한 바운디드 컨텍스트는 독립적으로 배포하고 모니터링하며 확장되는데, 이 역시 마이크로서비스가 갖는 특징이다!

바운디드 컨텍스트 간 관계

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

  • 가장 흔한 관계는 한쪽에서 API를 제공하고, 다른 한쪽에서 그 API를 호출하는 관계이다

    • 이 관계에서 API를 사용하는 바운디드 컨텍스트는 API를 제공 하는 바운디드 컨텍스트에 의존하게 된다

• 상류 컴포넌트 는 일종의 서비스 공급자 역할을 하며 하류 컴포넌트 는 그 서비스를 사용하는 고객 역할 을 한다

• 상류 컴포넌트 는 보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜 을 정의하고, 이를 공개한다

  • 상류 팀의 고객인 하류 팀이 다수 존재하면 상류팀은 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고, 이를 서비스 형태로 공개해서 서비스 일관성 을 유지할 수 있다

    • 이런 서비스를 공개 호스트 서비스 라고 한다

• 공개 호스트 서비스 의 대표적인 예가 검색 이다

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

  • 이때 검색은 상류 컴포넌트 가 되고, 블로그, 카페 게시판은 하류 컴포넌트 가 된다

• Anti-Corruption 계층

  • 외부 시스템과의 연동을 처리하는데 외부 시스템인 도메인 모델이 내 도메인 모델을 침범하지 않도록 막아주는 역할

    • 내 모델이 깨지는 것을 막아준다

• 공유 커널

  • 두 팀 간에 공통된 모델을 공유함으로써 중복된 설계를 막는 것

  • 장점

    • 중복을 줄여준다

  • 단점

    • 한 팀에서 임의로 모델을 변경하면 안 되며, 두 팀이 밀접한 관계를 유지해야 한다

• 독립 방식

  • 서로 통합하지 않는 방식

  • 두 바운디드 컨텍스트 간의 통합은 수동 으로 이루어진다

  • 수동으로 통합하는 방식이 나쁜 것은 아니지만, 규모가 커질수록 수동 통합에는 한계가 있으므로 규모가 커지기 시작하면 두 바운디드 컨텍스트를 통합 해야한다

  • 독립 방식으로 개발한 두 바운디드 컨텍스트를 통합하기 위해 별도의 시스템을 만들 수도 있다

컨텍스트 맵

• 바운디드 컨텍스트 간 관계를 표시한다

• 시스템의 전체 구조 를 보여준다

  • 하위 도메인과 일치하지 않는 바운디드 컨텍스트를 찾아 도메인에 맞게 바운디드 컨텍스트를 조절하고,

    • 사업의 핵심 도메인을 위해 어떤 바운디드 컨텍스트에 집중할지 파악하는 데 도움을 준다

• 컨텍스트 맵은 전체 시스템의 이해 수준을 보여준다

  • 즉, 시스템을 더 잘 이해하거나 시간이 지나면서 컨텍스트 간 관계가 바뀌면 컨텍스트 맵도 함께 바뀐다