도메인 주도 설계 첫걸음 4장

컨트랙트

바운디드 컨텍스트 모델은 서로 독립적으로 발전하고 구현될 수 있다. 그러나 바운디드 컨텍스트 자체는 독립적이지 않고 서로 상호작용 해야한다. 결국, 바운디드 컨텍스트 사이에는 항상 접점이 있는데 이것을 컨트랙트라 고 부른다.

왜 상호작용 해야하는데?

1. 비즈니스 프로세스 흐름: 예를 들어, 주문이 생성되고 처리되는 과정에서 고객 관리, 재고 관리, 결제 시스템 등 여러 컨텍스트 간의 상호작용이 필요할 수 있음
2. 데이터 공유: 서로 다른 컨텍스트 간에는 종종 데이터를 공유해야함. 예를 들어, 고객 정보를 처리하는 서비스는 주문 처리 시스템과 고객 정보를 공유해야 할 수 있음.
3. 업무 통합: 여러 바운디드 컨텍스트 간의 상호작용은 업무 통합을 가능하게. 서로 다른 컨텍스트 간에 정보를 교환하고 업무를 조율함으로써 전체 비즈니스 프로세스를 효율적으로 관리할 수 있음.
4. 경계 조정: 서로 다른 바운디드 컨텍스트 간의 상호작용은 컨텍스트 경계를 조정하는 데 도움이됨. 예를 들어, 한 컨텍스트에서 발생한 이벤트가 다른 컨텍스트에 영향을 주는 경우, 이를 통해 경계를 조정하고 업데이트할 수 있음.
5. 시스템 확장성: 바운디드 컨텍스트 간의 상호작용은 시스템의 확장성을 향상시킬 수 있다. 각 컨텍스트가 독립적으로 작동하면서도 필요에 따라 상호작용할 수 있기 때문에 시스템을 쉽게 확장하고 변경할 수 있음.

협력형 패턴 그룹

한 팀의 성공이 다른 팀의 성공에 달려있고, 그 반대도 마찬가지인 의존적 목표가 있는 팀에 해당. 다시 말해, 이 패턴이 적합한 요건은 팀의 커뮤니케이션과 협업 수준에 있음.

파트너십 패턴

• 바운디드 컨텍스트 간의 연동은 애드훅 방식으로 조정한다. 한 팀은 다른팀에게 API의 변경을 알리고 다른 팀은 충돌없이 이를 받아들인다.
• 연동의 조정은 양방향에서 한다.
• 양 팀은 차이점을 함께 해결하고 가장 적절한 솔루션을 찾기위해 협력하고 선정한다.

장점	단점
양방향 조장이 필요하지만 어느 정도는 독립적	팀 간의 잦은 동기화가 필수

 

주의 사항

• 커뮤니케이션의 어려움으로 인해 지리적으로 떨어져 있는 팀에게는 적합하지 않을 수 있음

공유 커널 패턴

• 바운디드 컨텍스트가 모델의 경계임에도 불구하고, 하위 도메인의 동일 모델이 여러 바운디드 컨텍스트에서 구현되는 경우
• 공유 커널(Shared Kernel)과 같은 공유 모델은 모든 바운디드 컨텍스트의 필요에 따라 설계된다.
• 권한 모델은 각 바운디드 컨텍스트에서 수정할 수 있고 이 변경은 다른 바운디드 컨텍스트에 영향을 준다.

장점	단점
지리적인 제약이나 조직의 정치적 문제로 커뮤니케이션 또는 협업이 어려워서 파트너십 패턴을 구현하기 어려운 경우에 대안 고려할 수 있음	겹치는 형태의 모델은 해당되는 바운디드 컨텍스트의 수명주기도 서로 엮이게 한다. 공유 모델의 변경은 바운디드 컨텍스트에 즉시 영향을 준다.
레거시 시스템을 점진적으로 현대화할 경우에 시스템을 서서히 바운디드 컨텍스트로 분해해서 공유 코드베이스로 만드는 것이 실용적인 중간 솔루션	어떤 방식이든 공유 커널에 대 한 변경이 생길 때마다 영향을 받는 모든 바운디드 컨텍스트와 연동 테스트(통합)를 수행해야 한다.
바운디드 컨텍스트의 연동 컨트랙트를 명시적으로 정의할 수 있음	공유 커널은 소스코드의 모든 변경이 즉시 연동되도록 구현해야함. 이를 지키지 않으면 모델의 일관성이 깨질 수 있음

 

주의 사항

• 변경의 연쇄 영향을 최소화하기 위해 양쪽의 겹치는 모델을 제한해서 바운디드 컨텍스트에서 공통으로 구현돼야 하는 모델의 일부분만 노출하도록 해야함.
• 공유 커널은 여러 바운디드 컨텍스트에 속하기 때문에 변경은 지속적으로 통합
• 중복 비용이 조율 비용보다 클 경우에 고려

사용자-제공자 패턴 그룹

• 제공자는 사용자에게 서비스를 제공한다.
• 서비스 제공자는 ‘업스트림(upsteam)’이고, 고객 또는 사용자는 ‘다운스트림(downstream)’이다.
• 업스트림과 다운스트림은 서로 독립적으로 성장할 수 있지만 연동 컨트랙트를 주도하는 권력의 불균형이 존재한다.

순응주의자 패턴

• 다운스트림 팀이 업스트림 팀의 모델을 받아들이는 바운디드 컨텍스트의 관계
• 제공자의 모델에 따라 정의된 연동 컨트랙트를 제공할 뿐이므로 사용자의 선택지는 이를 받아들이거나 떠나거나 둘 중 하나다.

업스트림이 노출한 컨트랙트가 산업 표준이거나 잘 구축된 모델 또는 다운스트림의 요건에 충분하다면 다운스트림이 팀의 자율성의 일부를 포기하는 결정은 정당화 될 수 있다.

충돌 방지 계층 패턴

• 힘의 균형이 업스트림에 치우쳐 있을 때 다운스트림 바운디드 컨텍스트가 업스트림에 순응하지 않을 경우 충돌 방지 계층을 통해 업스트림의 모델을 스스로에 맞게 가공할 수 있다.

충돌 방지 계층(ACL: anticorruption layer) 패턴은 다음 사례와 같이 제공자의 모델을 따르는 것을 원치 않거나 순응에 필요한 노력이 가치가 없을 경우를 다룬다.

조건	설명
다운스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함할 경우	핵심 하위 도메인은 각별한 주의가 필요하다. 제공자의 모델이 자칫 문제 도메인에 대한 모델링을 방해할 수 있다.
업스트림 모델이 사용자의 요건에 비효율적이거나 불편한 경우	바운디드 컨텍스트가 혼란에 순응하면 그 자체로 위험에 빠지게 된다. 이런 경우는 레거시 시스템과 연동할 때 종종 발생한다.
제공자가 컨트랙트를 자주 변경하는 경우	사용자는 잦은 변경으로부터 모델을 보호하기를 원한다.

오픈 호스트 서비스 패턴

• 오픈 호스트 서비스(OHS, Open-Host Service) 패턴은 충돌 방지 계층 패턴의 반대로 사용자 대신 제공자가 내부 모델 번역을 구현한다.
• 이 패턴은 제공자는 사용자를 보호하는 데 관심이 있고 힘의 균형이 사용자 측에 치우쳐 있다.
• 구현 모델의 변경으로부터 사용자를 보호하기 위해 퍼블릭 모델과 내부 구현 모델을 분리한다.

• 제공자의 퍼블린 인터페이스는 연동 지향 언어를 통해 사용자에게 더 편리한 프로토콜을 노출 시킨다. 이런 퍼블릭 프로토콜을 공표된 언어(published language)라고 한다.
• 오픈 호스트 서비스 패턴은 충돌 방지 계층 패턴의 반대다. 사용자 대신 제공자가 내부 모델 번역을 구현한다.
• 구현 모델과 연동 모델을 분리하면 업스트림 바운디드 컨텍스트는 다운스트림 컨텍스트에 영향을 주지 않으면서 자신의 구현을 자유롭게 발전시킬 수 있다.

• 또한 연동 모델을 분리하면 업스트림 바운디드 컨텍스트는 이미 공표된 언어의 여러 버전을 동 시에 노출할 수 있어서 사용자가 점진적으로 새로운 버전으로 이관할 수 있게 한다

분리형 노선

분리형 노선(Separated Ways) 패턴은 전혀 협력하지 않는 것이다.

• 커뮤니케이션 이슈
• 일반 하위 도메인
  • 일반 하위 도메인이 일반 솔루션과 연동하는 것이 쉽다면 각 바운디드 컨텍스트 내에서 각자 연동하는 것이 더 효과적일 수 있다.
  • 예를 들어 로깅 프레임워크처럼 기능 중복이 없을 경우보다 솔루션을 연동했을 때 복잡성이 커진다면 이를 서비스로 노출하는 것은 바람직하지 않다.
• 모델의 차이
  • 모델이 너무 달라서 순응주의자 관계가 불가능하고, 충돌 방지 계층을 구현하는 것도 기능 중복보다 효과적이지 않을 수 있다. 이런 경우에는 팀이 각자의 길을 가는 것이 더 비용 효과적이다.

결론

바운디드 컨텍스트는 독립적이지 않고 서로 상호작용 해야 한다.

파트너십	바운디드 컨텍스트는 애드혹 방식으로 연동된다.
공유 커널	두 개 이상의 바운디드 컨텍스트가 참여하는 모든 바운디드 컨텍스트가 공유하는 제한적으로 겹치는 모델을 공유해서 연동한다.
순응주의자	사용자는 서비스 제공자의 모델에 순응한다.
충돌 방지 계층	사용자는 서비스 제공자의 모델을 사용자의 요건에 맞게 번역한다.
오픈 호스트 서비스	서비스 제공자는 사용자의 요건에 최적화된 모델인 공표된 언어를 구현한다.
분리형 노선	협력과 연동보다 특정 기능을 중복으로 두는 것이 더 저렴한 경우다.