9. 도메인 모델과 경계
- 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 안됨
- ex1) 재고 관리, 주문, 배송에서 의미하는 상품 도메인의 의미가 모두 다름
- ex2) 시스템을 사용하는 도메인에서는 회원, 주문에서는 주문자, 배송에서는 보내는 사람
- 특정한 문맥 하에서 서로 다른 의미를 가질 수 있으므로 하위 도메인마다 모델을 만들어야 하며 이러한 경계를 바운디드 컨텍스트(Bounded Context)라 부름
바운디드 컨텍스트
- 바운디드 컨텍스트는 모델의 경계를 결정
- 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐
- 한 바운디드 컨텍스트는 실제로 사용자에게 기능을 제공하는 물리적 시스템
- 규모가 작은 기업은 전체 시스템을 하나의 팀에서 구현할 때도 있음
- 이럴 때 여러 하위 도메인을 하나의 바운디드 컨텍스트 안에서 구현해야 하는데 이떄 하위 도메인이 섞이지 않도록 해야함
- 하위 도메인마다 구분되는 패키지를 갖도록 하여 바운디드 컨텍스트를 만들어야 함
- 회원의 Member와 주문의 Orderer (애그리거트 루트, 밸류)
- 각각 다른 엔티티는 아니고 주문 바운디드 컨텍스트에서 값만 VO(Value Object)로 사용
- 카탈로그와 재고 바운디드 컨텍스트 (둘다 애그리거트)
- 카탈로그와 재고 바운디드 컨텍스트 각각에서 엔티티를 정의
바운디드 컨텍스트 구현
- 바운디드 컨텍스트에서는 표현, 응용, 인프라 및 테이블 스키마까지 포함됨
- 바운디드 컨텍스트마다 정해진 구현 방법은 없고 서로 다른 아키텍처, 구현 기술를 사용할 수 있음
바운디드 컨텍스트 간 통합
직접적인 바운디드 컨텍스트 통합
- 상품 추천 기능이 추가 된다 하면 추천 바운디드 컨텍스트가 새로 생김
- 상품 추천 기능 도메인 서비스는 인프라 영역에 위치
- 받아온 데이터를 현재 도메인의 Product 모델로 변환하는 작업 등도 수행
간접적인 바운디드 컨텍스트 통합
- 메시지 큐 사용
- 사용자가 조회한 상품 이력 등을 메시지 큐로 전달
MSA와 바운디드 컨텍스트
- MSA는 개별 서비스를 독립된 프로세스로 실행하고 각 서비스가 REST API나 메시징을 통해 통신하는 구조
- 바운디드 컨텍스트와 잘 어울림 - 바운디드 컨텍스트를 MSA로 구현하면 자연스럽게 컨텍스트 별로 모델이 분리됨
바운디드 컨텍스트 간 관계
- 가장 흔한 바운디드 컨텍스트 연결 방식은 API 제공 및 호출
- API 제공 측에 의존하게 됨
- 그래서 두 팀이 서로 개발 계획을 공유하고 일정을 협의해야 함
- 여기서 RecSystemClient는 외부 시스템의 도메인이 침범하지 않도록 막아주는 역할
- 해당 부분이 모델 변환을 처리해주기 때문에 다른 바운디드 컨텍스트의 모델에 영향을 받지 않고 내 도메인 모델을 유지할 수 있음
공유 커널
- 두 바운디드 컨텍스트가 같은 공유하는 모델을 가질 때 이를 공유 커널이라 함
- 중복을 줄일 수 있지만, 한 팀에서 임의로 모델을 변경해서는 안되며, 두 팀이 밀접한 관계를 유지해야 함
독립 방식
- 서로 통합하지 않음. 독립적으로 모델 발전
- 한 시스템이 변경되면 수동으로 바운디드 컨텍스트 수정 및 통합
- 이는 한계가 있으므로 규모가 커지기 시작하면 두 바운디드 컨텍스트를 통합해야 함
- 그럴 수 없다면 두 바운디드 컨텍스트를 통합해주는 별도 시스템을 만들어야 함
컨텍스트 맵
- 전체 비즈니스를 조망하기 위한 지도
- 각 바운디드 컨텍스트의 경계 및 어떤 관계를 맺고 있는지
- OHS(Open Host Service), ACL(Anti Corruption Layer) 표시
- 하위 도메인이나 조직 구조, 주요 애그리거트를 함께 표시하면 전체 관계 및 모델에 대한 이해에 도움이 됨