전략적 설계 - 바운디드 컨텍스트 연동

[nooose]

📅 2024.08.12 - 바운디드 컨텍스트 연동

📝 학습 내용 요약

• 주요 주제: 바운디드 컨텍스트 간 모델을 공유하는 여러 패턴을 공유

🧠 이해한 내용

• 핵심 개념: 바운디드 컨텍스트도 상호작용이 필요하다. 이것을 컨트랙트(contract)라고 부른다.

• 협력형(cooporation) 패턴

  • 파트너십 패턴: 한 팀은 다른 팀에게 API 변경을 알리고 다른 팀은 충돌 없이 받아들인다.
    양 팀 모두 커뮤니케이션이 원할할 때 사용할 수 있는 패턴이다.
  • 공유 커널 패턴: 공유할 수 있는 모델을 두고 각 팀이 공유 모델을 사용하는 패턴이다.
    공유 모델의 변경은 다른 팀에게 영향이 갈 수 있기 때문에 신중해야 한다.

• 사용자 - 제공자(customer - supplier) 패턴: 서비스 제공자는 upstream, 고객 또는 사용자는 downstream이다.

  • 순응주의자(conformist) 패턴: 업스트림이 노출한 모델을 다운스트림이 받아들이고 사용한다.
  • 충돌 방지 계층(ACL: anticorruption layer) 패턴: 제공자의 모델을 따르지 않고 다운스트림 핵심 하위 도메인에 맞게 변환하여 사용한다.
    잦은 변경, 핵심 모델링을 방해하는 요소가 있거나, 비효율적이라고 판단되면 사용하는 것이 좋다.
  • 오픈 호스트 서비스(OHS) 패턴: 업스트림이 다운스트림을 보호하기 위해 공표된 언어를 사용하여 여러개의 방식을 제공한다.

• 분리형 노선(seperated ways) 패턴: 전혀 협력하지 않는 것.

  • 바운디드 컨텍스트 내에서 각자 연동하여 해결하는 비용이 빠르다고 판단하면 사용한다.
  • 다음과 같은 이슈로 선택된다.
    • 복잡한 모델
    • 정치적인 문제로 커뮤니케이션 부재
    • 협업 의지가 없음

❓ 궁금한 점 및 논의할 주제

• 질문 1: DDD가 적용되어있지 않은 조직에서도 위 패턴들 중 하나 이상은 자연스럽게 사용중일 것 같다.
  각자 재직중인 회사에서는 어떤 패턴이 사용되는지 궁금하다.

🔍 추가 참고 자료

• Context Mapper

🗒 기타 메모

[dltkqnr]

학습 내용 요약

바운디드 컨텍스트는 컨트랙트를 통하여 상호작용을 하고, 여러 상호작용의 방식에 따라 다양한 도메인 주도 설계 패턴을 적용할 수 있다.

이해한 내용

커뮤니케이션(협력)의 정도, 힘의 주도권이 어디에 있는지 등 각자 상황에 따라서 다양한 도메인 주도 설계 패턴으로 나눌 수 있다.

• 커뮤니케이션이 원활하게 잘 되는가?
  →파트너십 패턴
• 참여하는 컨텍스트가 공유하는 겹치는 부분이 있는가?
  → 공유 커널 패턴
• 힘의 주도권이 어디에 있는가? → 사용자-제공자 패턴
  • ‘제공자’에게 있는가?
    → 사용자는 순응 한다. - 순응주의자 패턴
    • 사용자는 순응하고 싶지 않다? → ‘충돌 방지 계층’을 둬서 스스로에 맞게 가공한다. - 충돌 방지 계층 패턴
  • ‘사용자’에게 있는가?
    → 제공자는 사용자를 보호하고 최고의 서비스를 제공하기 위해서 스스로에 ‘오픈 호트스 서비스’를 둬서 편리한 프로토콜(공표된 언어) 를 제공한다 - 오픈 호스트 서비스 패턴

질문

[nonoro]

📝 학습 내용 요약

주요 주제: 바운디드 컨텍스트 간의 관계와 연동을 정의하는 도메인 주도 설계 패턴에 대해 알아보자!

🧠 이해한 내용

1. 협력형 패턴 그룹: 소통이 잘 되는 팀에서 구현된 바운디드 컨텍스트와 관련이 있는 패턴들

• 파트너십 패턴: 바운디드 컨텍스트 간의 연동이 애드혹 방식으로 조정.
  • 예시: 한 팀이 다른 팀에게 API 변경을 알리고, 다른 팀은 충돌 없이 이를 받아들인다
• 공유 커널 패턴: 여러 바운디드 컨텍스트가 하위 도메인의 동일 모델 또는 그 일부를 공유한다.
  • 공유 모델: 공유 모델은 모든 바운디드 컨텍스트에서 일관성을 유지해야 한다.
  • 주의사항
    • 공유 커널은 여러 바운디드 컨텍스트에 속하기 때문에 변경 시 지속적으로 통합되어야 한다.
    • 명분이 없다면 공유 커널은 사용하지 않는 것이 좋다.
  • 적용 시기: 공유 커널은 핵심 하위 도메인처럼 자주 변하는 하위 도메인에 적용된다.

2. 사용자-제공자 패턴 그룹: 협력형 그룹과 달리, 양 팀이 서로 독립적으로 성공할 수 있지만, 업스트림 또는 다운스트림 팀 간의 권력 불균형이 존재하는 패턴들

• 순응주의자 패턴: 다운스트림 팀이 업스트림 팀의 모델을 받아들이는 관계를 가진 패턴
• 충돌 방지 계층 패턴: 다운스트림 팀이 업스트림 팀의 모델을 사용자 필요에 맞게 가공하는 패턴
  • 제공자 대신 사용자가 내부 모델 번역을 구현.
• 오픈 호스트 서비스 패턴: 제공자가 사용자를 보호하고 최적화된 서비스를 제공
  • 충돌 방지 계층의 반대: 사용자 대신 제공자가 내부 모델 번역을 구현

3. 분리형 노선: 전혀 협력하지 않는 패턴

• 커뮤니케이션 이슈, 일반 하위 도메인, 모델의 차이 등이 존재
• 주의사항
  • 핵심 하위 도메인을 연동할 때 협업 없는 분리형 노선은 피해야 한다.
  • 하위 도메인의 중복 구현은 회사의 전략을 효과적으로 구현하는 것을 어렵게 만든다.

4. 컨텍스트 맵: 바운디드 컨텍스트 간의 연동 패턴을 시각적으로 분석하여 그린 맵

결론

• 바운디드 컨텍스트는 상호작용하며, 독립적이지 않다.
• 바운디드 컨텍스트 연동 방법
  • 파트너십: 애드혹 방식으로 연동.
  • 공유 커널: 제한적으로 겹치는 모델을 공유하여 연동.
  • 순응주의자: 사용자는 서비스 제공자의 모델에 순응.
  • 충돌 방지 계층: 사용자는 제공자의 모델을 사용자 요건에 맞게 번역.
  • 오픈 호스트 서비스: 제공자는 사용자의 요건에 최적화된 모델을 구현.
  • 분리형 노선: 특정 기능의 중복이 더 효율적일 때 사용.
• 컨텍스트 맵으로 바운디드 컨텍스트 간의 연동을 표현한다.

❓ 궁금한 점 및 논의할 주제

🔍 추가 참고 자료

🗒 기타 메모