도메인 주도 개발(DDD) 도메인 모델과 바운디드 컨텍스트

목차

도메인 모델과 경계

• 처음부터 도메인을 완벽하게 표현하는 단일 모델을 만들기는 어렵다 
• 도메인은 여러 하위도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 표현하기 어려움 
  
  

• 시스템을 사용하는 사람을 회원 도메인에서는 회원, 주문 도메인에서는 주문자, 배송도메인에서는 보내는 사람이라고 부른다.
• 각 모델은 명시적으로 구분되는 경계를 이용해 섞이지 않도록 해야함 
• 하위 도메인 모델이 섞이면 모델의 의미가 약해지고 각 도메인 별로 다른 요구사항을 반영하기 어려움 

 

---

바운디드 컨텍스트

• 모델은 특정 컨텍스트하에서 완전한 의미를 갖는데, 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다르다. 이렇게 구분되는 경계를 갖는 컨텍스트를 바운디드 컨텍스트라고 함
• 모델의 경계를 결정, 한 개의 바운디드 컨텍스트는 한 개의 모델을 가짐
• 기업의 팀 조직 구조에 따라 결정되기도 함 

 

• 주문의 하위도메인 -> 주문바운디드 컨텍스트, 결제바운디드 컨텍스트 따로 분리 
• 카탈로그와 재고관리가 명확하게 구분되지 않은 경우 두 하위도메인을 하나의 바운디드 컨텍스트에서 구현하기도함 

 

• 규모가 작은 기업은 전체 시스템을 한 개 팀에서 구현할 때도 있음 
• 주의할 점 : 하위 도메인의 모델이 섞이지 않도록 해야함 
• 바운디드 컨텍스트는 도메인 모델을 구분하는 경계
• 같은 사용자라도 주문, 회원 바운디드 컨텍스트가 가지는 모델은 달라짐

---

바운디드 컨텍스트 구현

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

 

 

• 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없음
• 리뷰는 CRUD방식으로 간편하게 구현이 가능하므로 DAO와 데이터중심 밸류 객체를 이용해 구현 

 

• 한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수 있음 
• CQRS : Command Query Responsibility Segregation 
  상태를 변경하는 명령기능, 내용조회하는 쿼리기능을 위한 모델을 구분하는 패턴 

 

---

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

• 마이크로 서비스 아키텍처는 애플리켘이션을 작은 서비스로 나누어 개발하는 아키텍처 스타일
• 개별 서비스를 독립된 프로세스로 실행하고 각 서비스가 REST API나 메시징을 이용해서 통신하는 구조 
• 바운디드컨텍스트는 모델의 경계를 형성하는데 바운디드 컨텍스트를 마이크로 서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리됨 

---

바운디드 컨텍스트 간 관계

• 대표적으로 두 바운디드 컨텍스트 간 관계를 연결하는 방법은 REST API

• 하류 카탈로그 컨텍스트는 상류 추천 컨텍스트가 제공하는 데이터와 기능에 의존 
• 카탈로그는 추천 상품을 보여주기 위해 추천 컨텍스트가 제공하는 REST API호출 
• 상류: 공급자, 하류 : 고객 
• 공개 호스트 서비스 : 상류팀의 고객인 하류팀이 다수 존재할 경우 여러 하류팀의 요구사항을 수용할 수 있는 API만들고 서비스 형태로 제공 (예: 상류 - 검색 , 하류 - 블로그, 카페, 게시판) 

 

• 공유 커널 
  • 두 팀이 하나의 모델을 개발해서 공유
  • 중복을 줄일 수 있음 
  • 일관성이 유지되어야하기 때문에 두 팀이 밀접한 관계를 형성하고 있어야함 
  • 개발이 지연되고 정체되는 문제가 생길 수 있음 
• 독립방식
  • 서로 통합하지 않고 독립적인 방식 
  • 두 바운디드 컨텍스트간 통합은 수동 
  • 규모가 커질 수록 수동통합에 한계가 있음 

 

---

컨텍스트 맵

• 개별바운디드 컨텍스트에 매몰되면 전체를 보지 못한다. 
• 컨텍스트 맵은 시스템 전체의 구조를 보여줌 

• 바운디드 컨텍스트 주요 영역에 주요 애그리거트를 함께 표시하면 모델에 대한 관계가 명확히 드러남 
• 오픈호스트서비스(OHS), 안티코럽션계층(ACL)