- 바운디드 컨텍스트(모델의 목적, 경계)없이는 모델을 구축할 수 없음
- 바운디드 컨텍스트 사이에는 항상 접점(상호작용이 필요)이 존재
- 이번장에서는 바운디드 컨텍스트 간의 연동을 정의하는 도메인 주도 설계 패턴에 대해서 배움
협력형 패턴 그룹
- 소통이 잘 되는, 팀간 의존적 목표가 있을때 해당함
- 파트너십 패턴
- 공유 커널 패턴
- 공유 커널 패턴이란?
- 여러 바운디드 컨텍스트에 걸쳐 공유커널(공유 모델)정의
- 예시
- 인가?
- 레거시 코드 분리
- 점진적으로 바운디드 컨텍스트로 분리, 공유 코드 베이스로 관리
- 구현시 변경사항은 즉시 반영되어야함
- 공유 커널을 사용해야하는 경우
- 중복 비용이 조율 비용보다 큰 경우
- 변경이 맞을수톡 통합 비용이 높아짐
- 핵심 하위 도메인처럼 많이 변하는 하위 도메인에 적용됨
- 공유 커널은 바운디드 컨텍스트 원칙에 위반됨
- 실용적인 예외, 사용하는데 명분이 필요하고 신중히 사용되어야함
- 어떤 이유든 커뮤니케이션이 어려울때 사용되며 적절한 조율이 필수
사용자-제공자 패턴 그룹
- 제공자(업스트림)가 사용자(다운스트림)에게 서비스를 제공하는 패턴
- 순응주의자 패턴
- 다운스트림 팀이 업스트림 팀의 모델을 받아들이는 패턴
- 충돌 방지 계층 패턴
- 다운스트림에 충돌 방지 계층(ACL: anticorruption layer)를 두는것
- 다운스트림에서 핵심 도메인 관리, 업스트림 비효율적, 비표준 사용, 업스트림이 컨트랙트를 자주 변경하는 경우
- 오픈 호스트 서비스 패턴
- 권력이 사용자에 있는경우 제공자를 적절히 핸들링하는 패턴
- 퍼블릭 인터페이스와 구현 모델을 분리 (내/외부를 분리, 외부와 상관없이 자유롭게 발전가능)
- 연동 지향 언어을 통해 사용자에게 더 편한 프로토콜(공표된 언어) 노출
- 여러버전으로 노출 가능
분리형 노선
- 전혀 협력하지 않는 패턴
- 커뮤니케이션 이슈, 일반 하위 도메인(각자 일반 솔루션과 연동), 모델간 차이(모델이 너무 다른경우)
컨텍스트 맵
- 시스템의 바운디드 컨텍스트간 연동 패턴 분석 결과를 시각적으로 표현한것
- 프로젝트 초기 도입해서 다함계 수정을 계속 반영하는것이 이상적
- https://contextmapper.org/ 라는 도구가 존재
결론