[Domain Driven Design] Bounded Context 연동

이홍준·2023년 7월 3일

DDD

목록 보기
4/10

1. Bounded Context 연동을 하는 이유

  • Bounded Conext의 모델은 서로 독립적으로 발전하고 구현될 수 있다. 하지만 그 자체는 독립적이지 못한다. → 시스템 요소가 독립적으로 구성될 수 없듯이 상호작용 해야만한다.
  • Contract: Bounded Context 사이에 있는 접점
  • 협력형, 사용자-제공자형 그리고 분리형 노선의 세 그룹으로 나누어 알아보기로 함.

2. 협력형 패턴 그룹 (cooperation)

  • 소통이 잘 되는 팀에서 구현된 바운디드 컨텍스트
  • 단일 팀에 의해 구현되는 것에 좋다.
  1. 파트너십 패턴
    • 바운디드 컨텍스트간의 연동은 애드혹(ad-hoc)방식으로 정한다. → 한 팀은 다른 팀에게 API의 변경을 알리고 다른 팀은 충돌 없이 이를 받아들인다.
    • 연동의 조정은 양방향
    • 성공적인 연동을 위해 잘 구축된 협업 실무, 높은 수준의 헌신, 그리고 팀 간의 잦은 동기화가 필수.
    • 지리적으로 떨어져 있는 팀에게는 적합하지 않을 수도 있다.
  2. 공유 커널 패턴
    • 바운디드 컨텍스트에가 모델의 경계임에도 불구하고, 여전히 하위 도메인의 동일 모델 혹은 그 일부가 여러 다른 바운디드 컨텍스트에서 구현되는 경우가 많다.
    • 공유커널과 같은 공유 모델은 모든 바운디드 컨텍스트의 필요에 따라 설계됨 → 일관성 유지
    • 각각의 사용자는 권한을 직접 부여 받거나 소속된 단위 조직에서 상속받는다. → 이 모델을 사용하는 다른 모든 바운디드 컨텍스트에 영향을 준다.
  3. 공유 범위
    • 겹치는 형태의 모델은 서로의 생명주기에도 영향을 준다.
    • 변경의 연쇄 영향을 최소화 하려면 양쪽의 겹치는 모델을 제한해서 바운디드 컨텍스트에서 공통으로 구현돼야 하는 모델의 일부분만 노출 하도록 해야함. → 제공될 의도가 있는 연동 관련 컨트랙트와 자료구조만으로 구성하는 것이 이상적
  4. 구현
    • 공유 커널은 소스코드의 모든 변경이 이를 사용하는 모든 바운디드 컨텍스트에 즉시 반영되도록 구현된다.
  5. 공유 커널을 사용해야 하는 경우
    • 중복 비용과 조율 비용의 비율이 가장 큰 중요한 기준 → 모델의 변동성에 따름
    • 공유 커널은 핵심 하위 도메인처럼 많이 변하는 하위 도메인에 적용된다.

3. 사용자-제공자 패턴 그룹 (customer - supplier)

  • 협력 그룹의 경우와는 다르게 양 팀은 서로 독립적으로 성공할 수 있다.
  • 서비스 제공자는 upstream이고 고객 또는 사용자는 downstream이다.
  • 하지만 힘의 차이로 컨트랙트 주도의 불균형이 이루어진다.
  1. 순응주의자 패턴
    • 힘의 균형이 서비스를 제공하는 업스트림 팀에 있는 경우가 있다.
    • 사용자의 요구를 지원할 동기가 없는 경우가 그렇다.
  2. 충돌 방지 계층 패턴(ACL: Anticorruption layer)
    • 힘의 균형은 업스트림 서비스에 치우쳐져있기 때문에 다운스트림 바운디드 컨텍스트가 컨텍스트 모델을 필요에 맞게 가공할수 있다.
    • 다운 스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함할 경우 → 제공자의 모델이 문제 도메인에 대한 모델링을 방해할 수 있어 핵심 하위 도메인은 각별한 주의가 필요함.
    • 업스트림 스트림이 사용자의 요건에 비효율적이거나 불편한 경우 → 레거시 시스템과 연동할때 보통 바운디드 컨텍스트가 혼란에 순응하면 그 자체로 위험에 빠지게 된다.
    • 제공자가 컨트랙트를 자주 변경하는 경우 → 사용자는 잦은 변경으로부터 모델을 보호하기를 원한다. 그래서 충돌 방지 계층을 통해 영향을 변환 장치에만 미치게 함.
  3. 오픈 호스트 서비스 패턴(OHS: open-host service)
    • 힘이 사용자 측에 있을 경우에 해당
    • 제공자는 사용자를 보호하고 가능한 최고의 서비스를 제공하는 데 관심이 있는 경우 사용
    • 제공자의 퍼블릭 인터페이스는 자신의 유비쿼터스 언어를 따르는 대신에, 연동 지향언어를 통해 사용자에게 더 편리한 프로토콜을 노출하려함. → 공표된 언어(published Lanaguage)
    • 충돌 방지 계층 패턴의 반대 → 사용자 대신 제공자가 내부 모델 번역을 구현함.
    • 업스트림 바운디드 컨텍스트는 영향을 주지 않으면서 자신의 구현을 자유롭게 발전 시킬수 있음 → 사용자가 점진적으로 새로운 버전으로 이관할수 있게됨.

4. 분리형 노선

  • 전혀 협력하지 않는 패턴 → 협업 의지가 없거나 할 수 없는 경우 사용
  • 로깅 프레임워크일 경우 해당
profile
I'm not only a web developer.

0개의 댓글