9.1 도메인 모델과 경계
- 하위 도메인 마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있음
- 하위 도메인 마다 사용하는 용어가 다르므로 올바른 도메인 모델 개발을 위해선 하위 도메인 마다 모델을 만들어야 함
- 모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 가짐
- 같은 제품이라도 컨텍스트에 따라 의미가 다름
- 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에선 바운디드 컨텍스트라고 함.
9.2 바운디드 컨텍스트
- 바운디드 컨텍스트는 모델의 경계를 결정하며, 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 가짐
- 용어를 기준으로 구분
- 실제로 사용자에게 기능을 제공하는 물리적 시스템
- 도메인 모델은 바운디드 컨텍스트 안에서 도메인을 구현함
- 이상적으로 하위 도메인과 바운디드 컨텍스트가 일대일 관계를 가지면 좋겠지만 그렇지 않을 때가 많으며 기업의 팀 조직 구조에 따라 결정되기도 함
- 규모가 작은 기업은 전체 시스템을 한 개 팀에서 구현할 때도 있음
- 주의할 점
- 여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때, 하위 도메인의 모델이 섞이지 않도록 하기
- 전체 하위 도메인을 위한 단일 모델을 만들고 싶은 유혹에 빠지기 쉬움
- 비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현하여 하위 도메인을 위한 모델이 뒤섞이지 않도록 하는 효과를 낼 수 있음
- 바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 구현하는 하위 도메인에 알맞는 모델을 포함
9.3 바운디드 컨텍스트 구현
- 바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하기 위해 표현 영역, 응용 서비스, 인프라 영역 등을 모두 포함
- 도메인 모델의 구조가 바뀌면 DB 테이블 스키마도 함께 변경해야 함
➡️ 해당 테이블도 바운디드 컨텍스트에 포함됨
- 모든 바운디드 컨텍스트를 반드시 도메인 주도로 개발할 필요는 없음
➡️ 복잡한 도메인 로직이 없을 경우 서비스-DAO 구조를 사용할 수도 있음
- 한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수도 있음
- ex. CQRS 패턴: 상태를 변경하는 명령 기능과 내용을 조회하는 쿼리 기능을 위한 모델을 구분하는 패턴
- 각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수도 있음
- 바운디드 컨텍스트가 사용자에게 보여지는 UI를 갖지 않고 JSON 으로 응답할 수 있음
9.4 바운디드 컨텍스트 간 통합
-
예제 상황
- 쇼핑 사이트에서 매출 증대를 위해 카탈로그 하위 도메인에 개인화 추천 기능을 도입
- 추천 시스템을 담당하는 팀이 새로 생겨서 해당 팀에서 주도적으로 추천 시스템을 만들기로 함
- 카탈로그 하위 도메인에 추천 기능을 위한 바운디드 컨텍스트가 생기게 됨.
- 두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생
➡️ 이때 카탈로그 컨텍스트와 추천 컨텍스트의 도메인 모델이 서로 다름 - 카탈로그는 제품을 중심으로 도메인 모델을 구현하지만 추천은 추천 연산을 위한 모델을 구현함
- 카탈로그 시스템은 추천 시스템에서 받은 상품 모델을 사용하기보다는 카탈로그 도메인 모델을 사용해서 추천 상품을 표현해야 하므로, 카탈로그의 모델을 기반으로 하는 도메인 서비스를 사용해서 추천 기능을 표현해야 함.
-
도메인 서비스를 구현한 클래스는 인프라스트럭처 영역에 위치
➡️ 이 클래스는 외부 시스템과의 연동을 처리하고 외부 시스템의 모델과 현재 도메인 모델 간의 변환을 책임짐
-
두 모델 간의 변환 과정이 복잡하면 변환 처리를 위한 별도 클래스를
만들고 이 클래스에서 변환을 처리해도 됨.
-
바운디드 컨텍스트 통합 방식
- 직접 통합: REST API 호출
- 간접 통합: 메세지 큐
- 두 바운디드 컨텍스트가 메세지의 데이터 구조를 맞춰야 함
- 어떤 관점에서 모델을 사용하느냐에 따라 구현 코드가 달라지게 됨
- 메세징 큐에 담을 구조를 협의할때 그 큐를 누가 제공하느냐에 따라 데이터 구조가 결정됨
마이크로서비스와 바운디드 컨텍스트
- MSA: REST API나 메시징 큐를 이용해서 통신하는 구조
- MSA는 단순 유행을 지나 많은 기업에서 자리를 잡아가고 있음
- 각 바운디드 컨텍스트는 모델의 경계를 형성, 바운디드 컨텍스트를 마이크로 서비스로 구현하면 자연스럽게 컨텍스트 별로 모델이 분리됨.
- 마이크로서비스마다 프로젝트를 생성하므로 바운디드 컨텍스트마다 프로젝트를 만들게 됨
➡️ 이것은 코드 수준에서 모델을 분리하여 두 바운디드 컨텍스트가 섞이지 않도록 해줌 - 별도 프로세스로 개발한 바운디드 컨텍스트는 독립적으로 배포하고 모니터링하며 확장되는데 이 역시 마이크로서비스가 갖는 특징
9.5 바운디드 컨텍스트 간 관계
- 두 바운디드 컨텍스트간 관계 중 가장 흔한 관계는 한쪽에서 API 를 제공하고 다른 한쪽에서는 그 API를 호출하는 관계
- 이 관계에서 API를 사용하는 바운디드 컨텍스트는 API를 제공하는
바운디드 컨텍스트에 의존하게 됨.
공개 호스트 서비스(OPEN HOST SERVICE)
- 상류 팀의 고객인 하류 팀이 다수 존재하면 상류 팀은 여러 하류팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개하여 일관성을 유지할 수 있음
- ex. 검색
- 상류 컴포넌트: 검색 시스템
- 하류 컴포넌트: 블로그, 카페, 게시판 등
- 상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따름
➡️ 하류 컴포넌트는 자신의 모델에 영향을 주지 않도록 보호해 주는 완충 지대(안티코럽션 계층(Anticorruption Layer))를 구축해야 함
공유 커널(SHARED KERNEL)
- 두 바운디드 컨텍스트가 같은 모델을 공유하는 경우, 두 팀이 공유하는 모델을 공유 커널이라고 부름
- 같은 서비스를 구축하는 두 팀에서 해당 서비스 모델을 공유함으로써 공통된 개발을 막을 수 있음
- 장점: 공통된 개발을 줄일 수 있음
- 단점: 임의로 모델을 변경해서는 안되며 두 팀이 밀접한 관계를 유지해야 함
- 두 팀이 밀접한 관계를 형성할 수 없다면 공유 커널을 사용할 때의 장점보다
공유 커널로 인해 개발이 지연되고 정체되는 문제가 더 커지게 됨
독립 방식 관계(SEPARATE WAY)
- 서로 통합하지 않는 방식
- 두 바운디드 컨텍스트간에 통합을 하지 않으므로 서로 독립적으로 모델을 발전시킴
- 두 바운디드 컨텍스트간에 통합은 사용자가 직접 수동으로 이루어짐
➡️ 수동으로 통합하는 방식이 나쁜 것은 아니지만 규모가 커질수록 한계가 있으므로 두 바운디드 컨텍스트를 통합해야 함
9.6 컨텍스트 맵
- 컨텍스트 맵: 바운디드 컨텍스트 간의 관계를 표시한 것이다.
- 전체 비즈니스를 조망하기 위해 생성
➡️ 오픈 호스트 서비스(OHS) 와 안티코럽션 계층(ACL)이 표시되어 있음 - 바운디드 컨텍스트 영역에 주요 애그리거트를 함께 표시하면 모델에 대한 관계가 더 명확히 드러남
- 추가로 하위 도메인이나 조직 구조를 함께 표시하면 도메인을 포함한 전체 관계를 이해 하는데 도움이 됨
- 컨텍스트 맵은 시스템의 전체 구조를 보여줌
➡️ 하위 도메인과 일치하지 않는 바운디드 컨텍스트를 찾아 도메인에 맞게
바운디드 컨텍스트를 조절하고 사업의 핵심 도메인을 위해 조직 역량을
어떤 바운디드 컨텍스트에 집중할지 파악하는데 도움을 줌 - 컨텍스트 맵을 그리는 규칙: 따로 없음, 간단한 도형과 선을 이용해서
각 컨텍스트의 관계를 이해할 수 있는 수준에서 그리기 - 컨텍스트 맵은 전체 시스템의 이해 수준을 보여줌. 즉, 시스템을 더 잘 이해하거나 시간이 지나면서 컨텍스트간 관계가 바뀌면 컨텍스트 맵도 함께 바뀔 수 있음
