[도메인 주도 설계] 도메인 모델과 바운디드 컨텍스트

도메인 모델과 경계

도메인을 완벽하게 표현하는 단일 모델을 만드려는 시도를 하지 말자!!

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

• 하위 도메인마다 같은 용어라도 의미가 다를 수 있음
• 하위 도메인마다 같은 대상이라도 지칭하는 용어가 다를 수 있음

따라서, 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야한다.

case1. 같은 용어라도 의미가 다른 경우 (feat. 상품 모델)

• 카탈로그 도메인에서의 상품
  • 상품 이미지, 상품명, 상품 가격, 상세 설명 과 같은 상품 정보 위주
• 재고 관리 도메인에서의 상품
  • 실존하는 개별 객체를 추적하기 위한 목적으로 사용
• 주문 도메인에서의 상품
• 배송 도메인에서의 상품

case2. 같은 대상이라도 지칭하는 용어가 다른 경우

• 회원 도메인에서는 회원
• 주문 도메인에서는 주문자
• 배송 도메인에서는 보내는 사람

같은 대상이지만 용어가 다름

중요한점

• 각 모델은 명시적으로 구분되는 경계를 가져 섞이지 않도록 해야 한다.
  • 여러 하위 도메인의 모델이 섞이기 시작하면 모델의 의미가 약해진다.
  • 각 하위 도메인별로 다르게 발전하는 요구사항을 모델에 반영하기 어려워 진다.
• 모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖아야 한다.

같은 제품이라도 카탈로그 컨텍스트, 재고 컨텍스트에서의 의미는 서로 다르다.
이렇게 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트(Bounded Context)라고 부른다.

바운디드 컨텍스트(Bounded Context)

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

바운디드 컨텍스트 구분

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

• 같은 사용자이지만, 주문 바운디드 컨텍스트와 회원 바운디드 컨텍스트가 갖는 모델은 달라진다.
  • 회원의 Member는 애그리거트 루트, 주문의 Orderer는 밸류
• 같은 상품이지만, 카탈로그 바운디드 컨텍스트와 재고 바운디드 컨텍스트는 각 컨텍스트에 맞는 모델을 갖는다.
  • 카탈로그의 Product는 상품이 속할 Category와 연관을 갖지만, 재고의 Product는 카탈로그의 Category와 연관을 맺지 않는다.

바운디드 컨텍스트 : 하위 도메인 = 1 : 1 이 아닌 예외 케이스

이상적으로는 하위 도메인과 바운디드 컨텍스트가 일대일 관계를 가지면 좋겠지만 현실은 그렇지 않을 때가 많다.(이것이 일반적이다)
바운디드 컨텍스트는 기업의 팀 조직 구조에 따라 결정될 가능성이 높다. (구현하는 팀 기준)

1. 하나의 하위 도메인에 여러개의 바운디드 컨텍스트가 존재하는 경우

• 하나의 도메인을 서로 다른 팀에서 구현한 경우 하나의 도메인에 여러 바운디드 컨텍스트가 생성될 수 있다.
• 주문 하위 도메인
  • 주문을 처리하는 팀 (주문 바운디드 컨텍스트)
  • 복잡한 결제 금액 계산 로직을 구현하는 팀 (결제 금액 계산 바운디드 컨텍스트)

하나의 하위 도메인, 여러개의 바운디드 컨텍스트

2. 두 하위 도메인이 하나의 바운디드 컨텍스트에 구현된 경우

• 용어를 명확하게 구분하지 못해 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.
• 카탈로그와 재고 관리가 아직 명확하게 구분되지 않은 경우 두 하위 도메인을 하나의 바운디드 컨텍스트에서 구현하기도 한다.

두 하위 도메인, 하나의 바운디드 컨텍스트

3. 여러 하위 도메인을 하나의 바운디드 컨텍스트에 구현한 경우

• 소규모 쇼핑몰은 하나의 시스템에서 회원, 카탈로그, 재고, 구매, 결제와 관련된 모든 기능을 제공한다.
  • 즉, 여러 하위 도메인을 한 개의 바운디드 컨텍스트에서 구현

여러 하위 도메인을 하나의 바운디드 컨텍스트로 구현

• 하위 도메인의 모델이 섞이지 않도록 주의해야 한다.
  • 한 프로젝트에 각 하위 도메인의 모델이 위치하면 아무래도 단일 모델을 만들고 싶은 유혹에 빠지기 쉽기 때문
  • 단일 모델을 만든다면, 도메인 모델이 개별 하위 도메인을 제대로 반영하지 못해 하위 도메인별 기능을 확장하기 어렵게 되고 서비스 경쟁력을 떨어뜨림
  • 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 패키지로 구분을 지어 구현해야 한다.

바운디드 컨텍스트(Bounded Context)구현하기

바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는 데 필요한 표현, 응용, 인프라스트럭쳐 영역을 모두 포함한다.
모든 바운디드 컨텍스트는 도메인 주도로 개발할 필요가 없으며, 복잡한 로직을 갖고 있지 않으면 CRUD 방식으로 구현해도 된다. (DAO와 데이터 중심의 밸류 객체를 이용해서 리뷰 기능을 구현해도 유지 보수하는 데 큰 문제가 없다.)

한 바운디드 컨텍스트에 CQRS를 적용할 수 있다.

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

CQRS 적용 구현

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

마이크로 서비스?

• 마이크로서비스는 애플리케이션을 작은 서비스로 나누어 개발하는 아키텍처 스타일
• 개별 서비스를 독립된 프로세스로 실행하고 각 서비스가 REST API(직접 통합)나 메시징(간접 통합)을 이용해서 통신하는 구조를 갖음
• 넷플릭스나 아마존 같은 선도기업뿐만 아니라 많은 기업이 마이크로서비스 아키텍처를 수용하는 추세

마이크로서비스의 특징은 바운디드 컨텍스트와 잘 어울린다.

• 각 바운디드 컨텍스트는 모델의 경계를 형성하는데 바운디드 컨텍스트를 마이크로서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리된다.
• 코드기준으로 생각하면 마이크로서비스마다 프로젝트를 생성하므로 바운디드 컨텍스트마다 프로젝트를 만들게 된다. 코드 수준에서 모델을 분리하여 두 바운디드 컨텍스트의 모델이 섞이지 않도록 해준다.

 

출처) 도메인 주도 개발 시작하기 - 최범균