Bounded Context간의 Relationship

https://www.oreilly.com/library/view/what-is-domain-driven/9781492057802/ch04.html

 

* 파트너십 Partnership
두 가지 컨텍스트 안의 팀이 성공이나 실패를 함께한다면 협업관계가 나타나야 한다. 
이 팀들은 개발과 통합의 공동 관리를 위한 잘 조정된 기획 과정을 도입한다. 
팀들은 양측 시스템 모두의 개발 요구를 수용할 수 있는 인터페이스를 만들어 나가기 위해 반드시 협력해야 한다. 
상호의존적인 기능은 반드시 일정을 세워 같은 릴리스에서 완성할 수 있도록 해야 한다.


* 공유 커널 Shared Kernel
모델에서 공유된 부분과 이에 관련된 코드는 아주 가까운 상호의존성을 형성하는데,
이는 설계 작업을 도울 수도 있고 약화시킬 수도 있다.
도메인 모델에서 팀이 공유하기로 동의한 부분집합 일부를 명시적 경계로 지정하자.
커널(핵심)은 작게 유지하자.
이 명시적 공유는 특별한 상태에 놓이며, 다른 팀과의 상의 없이 변경해선 안 된다.
커널 모델을 단단하게 유지하고 팀의 유비쿼터스 언어를 정돈해주는 지속적 통합 프로세스를 정의하라.

* 고객-공급자 개발 Customer-Supplier Development
두 팀이 업스트림과 다운스트림의 관계에 있고
업스트림 팀의 성공이 다운스트림 팀의 운명과 상호의존적이라면,
광범위한 결과를 초래할 다양한 방법으로 다운스트림 팀의 요구를 수용해야 한다.
업스트림 계획이 다운스트림 우선순위에 영향을 미친다.
협상과 작업 예산 편성을 다운스트림의 요구사항에 맞춰 진행해서, 모든 사람에게 약속과 일정을 이해시키자.

* 순응주의자 Conformist
업스트림팀이 다운스트림팀의 요구사항을 제공해줄 동기가 전혀 없는 업스트림/다운스트림 관계에서,
다운스트림팀은 속수무책의 상황에 빠진다.
이타주의가 업스트림팀의 개발자에게 동기를 부여해줄 수도 있지만 실현 가능성은 낮다.
다운스트림팀은 맹목적으로 업스트림팀의 모델을 준수해서, 바운디드 컨텍스트 사이에 나타나는 변환의 복잡성을 제거 한다.

* 부패 방지 계층 Anti Corruption Layer (ACL)
변환 계층은 협조적인 팀 사이에서 잘 설계된 바운디드 컨텍스트를 연결할 때 간결하고 우아해질 수 있다.
그러나 공유커널, 파트너, 또는 고객-공급자 관계를 만들기에 제어나 의사소통이 적절하지 않다면 변환은 좀 더 복잡해진다.
변환 계층은 좀 더 방어적인 색깔을 띠게 된다. 
다운스트림 클라이언트에는 분리 계층을 만들어서, 
업스트림 시스템의 기능을 여러분 자신이 소유한 도메인 모델의 맥락에 맞춰 제공하라.
이 계층은 기존의 인터페이스를 통해 다른 시스템과 대화하며,
다른 시스템을 수정할 필요가 거의 없거나 전혀 없다.
이 계층은 내부적으로 필요에 따라 단방향이나 양방향으로 두 모델 사이에서 변환을 수행한다.

* 오픈 호스트 서비스 Open Host Service (OHS)
여러분의 서브시스템에 접근할 수 있도록 해주는, 서비스 집합으로서의 프로토콜을 정의하자.
프로토콜을 열어서 여러분과 통합해야하는 모든 이가 사용할 수 있도록 해주자.
단일 팀의 특이한 요구가 있지 않는 이상, 이 프로토콜을 강화하고 확장해서 새로운 통합 요구사항에 대응하자.
그 이후에 일회성 변환기를 사용해 예외적인 상황에 대응하는 프로토콜을 추가함으로써,
공유된 프로토콜이 단순함과 일관성 을 유지 하도록 하자.
이 패턴은 바운디드 컨텍스트 클라이언트와 상호작용하는 REST 기반 리소스로 구현할 수 있다. 일반적으론 오픈 호스트 서비스를 원 격 프로시저 호출 RPC(Remote Procedure Call)로 생각하지만, 메시지 교환을 사용 해 구현할 수도 있다. (p162)

* 발행된 언어 Pushed Language (PL)
두 바운디드 컨텍스트 모델 사이의 변환은 공통 언어를 필요로 한다.
공통의 의사소통 수단으로서 필수적인 도메인 정보를 표현할 수 있는 잘 문서화된 공유 언어를 사용해,
필요에 맞춰 변환을 수행하자. 발행된 언어는 오픈 호스트 서비스와 종종 결합된다.
표현은 XML과 JSON을 포함 할 수 있다 (p163)

* 분리된 방법 Separate Ways
요구사항을 정의할 때는 무자비해야만 한다.
만약 두 기능성 집합 사이에 유의미한 관계가 없다면, 이들은 서로가 완전히 분리돼야 한다.
통합에는 항상 높은 비용이 필요하며, 그에 따른 유익함은 너무 작을 때 가 많다.
바운디드 컨텍스트가 다른 것과 아무 연관이 없음을 선포해서, 개발자가 작은 범위 내에서 단순하고 전문화된 솔루션을 찾도록 해주자.

* 큰 진흙 공 Big Ball of Mud
기존 시스템을 조사해나가다 보면 여러 모델이 서로 뒤 섞이고 경계는 일정하지 않은 상황에서 시스템을 구성하는 부분 (종종 거대한 형태도 나타난다) 들을 찾게 된다. (Monolith)
이런 어지러운 상황 전체를 아우르는 경계를 그리고 큰 진흙공으로 선언하자.
이 컨텍스트 안에 세련된 모델링을 적용해보려 애쓰지 말자.
이런 시스템이 다른 컨텍스트 안으로 제멋대로 퍼져나가려는 경향에 주의하자.

- Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p153~155

 

..

 

여러분의 팀은 
그 진흙투성이 돌덩이를 유지하고 있는 팀이
여러분이 의존하고 있는 API의 새로운 버전을 제공하리라고 가정하고 있지만,
(큰 진흙 덩어리의 Monolith와 인터페이스해야하고 거기서 어떤 기능을 API로 제공하리라 생각할 수 있지만,
그걸 실제 계획에 넣었을수도 있지만)

그 팀은 줄 생각이 없거나
심지어 여러분이 무슨 생각을 하는지도 모른다면
어떤 일이 일어날지 상상해보자.

여러분의 팀은 진흙으로 범벅이 된 고객-공급자 관계에 의지하고 있는 것이다.
그러나 그들은 지금 갖고 있는 것만 제공함으로써,
그 레거시 팀은 여러분의 팀을 미처 생각지 못했던 순응주의자의 관계로 몰아가게 된다.

프로젝트에서 얼마나 늦게 이 나쁜 소식을 들었는지에 따라,
보이진 않지만 실제로 존재하는 이 관계가
여러분의 프로젝트를 지연시키거나 실패하게 만들 수 있다.

초기에 컨텍스트 맵을 그리면
여러분이 의지하는 모든 다른 프로젝트들과의 관계를 신중히 생각해보도록 강요받게 된다.
(ASIS CM을 그리면 이러한 TOBE의 Risk를 사전에 생각해보고 계획할 수 있다)

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논 p149

 

..