[DDD] SEPARATE WAY / OPEN HOST SERVICE / PUBLISHED LANGUAGE

SEPARATE WAY

문제

• 통합에는 언제나 비용이 많이든다.
• 때로는 통합의 혜택이 적은 경우도 있다.

해결

• BOUNDED CONTEXT가 다른 것과 아무런 관계도 맺지 않도록 선언해서 개발자들이 이 작은 범위 내에서 단순하고 특화된 해결책을 찾을 수 있게 하라.
• 일부 대안은 사전에 차단된다.

But

• 완벽하게 격리된 상태에서 개발된 모델을 병합하기란 대단히 어렵다.
• 통합이 필요한 것으로 밝혀진다면 번역 계층이 필요할 것이다.
• 번역계층은 복잡할 수 있다.

OPEN HOST SERVICE

문제

• 어떤 하위 시스템을 다른 여러 하위 시스템과 통합해야 할 경우 각 하위 시스템에 대한 번역기를 조정한다면 팀 전체가 교착 상태에 빠질 수 있다.
• 변경이 발생할 때는 유지보수하고 걱정해야 할 일이 더 많다.

해결

• 하위 시스템 접근과 관련된 프로토콜을 일련의 SERVICE로 정의하라.
• 프로토콜을 공개해서 개발 중인 시스템과 통합하고자 하는 모든 이들이 해당 프로토콜을 사용할 수 있게 하라.
• 특정한팀에서 요청해 오는 독특한 요구사항은 제외하라.
• 특수한 경우에는 일회성 번역기로 프로토콜을 보강해서 공유 프로토콜을 단순하고 일관되게 유지하라.

PUBLISHED LANGUAGE

문제

• 두 BOUNDED CONTEXT의 모델 간에 이뤄지는 번역에는 공통의 언어가 필요하다.
• 기존 도메인 모델로 직접 번역하거나 기존 모델에서 직접 번역해 오는 좋은 해결책이 아닐지도 모른다.
• 한 모델을 데이터 교환 언어로 사용한다면 해당 모델은 본질적으로 굳어질 테고 새로운 개발 요구사항에 대응하지 못할 것이다.

해결

• 필요한 도메인 정보를 표현할 수 있는 적절히 문서화된 공유 언어를 공통의 의사소통 매개체로 사용해서 필요에 따라 해당 언어로, 또는 해당 언어로부터 번역을 수행하라.

정리

• 이번 장에서는 통합이 또 다른 방식을 살펴보았다. 통합에 어렵다면 완전 각자의 길을 가는 방법부터 좀 더 협력적으로 통합을 이뤄내는 OPEN HOST SERVICE, PUBLISHED LANGUAGE 방식을 알아보았다. 소프트웨어 개발에서 다양한 사람이 함께 협업하기 위해 이러한 방식들이 많이 사용된다. 그러므로 각 패턴의 장단점을 파악해서 상황에 맞는 결정을 내릴 수 있어야겠다.
  이 모든 게 팀 상황, 시스템 상황, 모든 환경이 복합적으로 고려돼야 하는 점이 중요한 것 같다.