Context Map에서 관계를 명시하는 방법

**DDD**에서 Bounded Context 간의 관계 설명 및 표현

Context Map (source from: oreilly.com)

FACT ^{주장/현상/관념}

컨텍스트 맵(Context Map)은 도메인 간의 관계를 시각적으로 표현하는 도구이며, 주로 DDD(Domain-Driven Design)에서 Bounded Context 간의 관계를 명확히 정의하는 데 사용됩니다.

컨텍스트 간의 관계는 파트너십(Partnership), 공유 커널(Shared Kernel), 고객-공급자(Customer-Supplier) 등 아래 표와 같이 정의되며, 이를 명확히 표현하는 방법은 다음과 같습니다.

 

컨텍스트 간 관계 유형 및 표현 방법

관계 유형	설명	표현 방식 (컨텍스트 맵에서)
파트너십 (Partnership)	두 컨텍스트가 공동 목표를 가지고 협력하는 관계.	화살표 없는 연결선, 협력 메모 추가
공유 커널 (Shared Kernel)	두 컨텍스트가 공통된 일부 모델(코드, 데이터 등)을 공유하는 관계.	점선 또는 특정 색상 블록으로 공유 영역 표시
고객-공급자 (Customer-Supplier)	한 컨텍스트(공급자)가 다른 컨텍스트(고객)에 서비스를 제공하는 관계.	방향성 있는 화살표 (→ : 공급자가 고객에게 영향)
순응자 (Conformist)	고객이 공급자의 모델을 그대로 따르는 관계.	일방적인 화살표 (→, 고객이 공급자를 따름)
공개 호스트 서비스 (Open Host Service)	특정 프로토콜이나 API를 통해 여러 컨텍스트가 이용할 수 있도록 서비스 제공.	중앙 API 모듈로 묶고 여러 컨텍스트가 연결
반복적 상속 (Anticorruption Layer, ACL)	한 컨텍스트가 다른 컨텍스트의 영향을 줄이기 위해 중간 계층을 둠.	중간 ACL 계층을 추가하고 양쪽 연결

 

아래에서는 각 컨텍스트 관계 유형별로 실제 사례를 기반으로 한 예제를 만들어 표현해 보겠습니다.

---

CHECK ^{검증/실상/검토}

1. 파트너십 (Partnership)

예제:

🚀 "배달 서비스와 결제 서비스 간 협업"

• 배달 플랫폼과 결제 서비스는 긴밀한 협력 관계를 유지하며, 주요 변경 사항을 조율해야 한다.
• 배달 서비스가 결제 시스템을 변경하면, 결제 서비스도 반드시 대응해야 한다.

📌 컨텍스트 맵 표현:

[ 배달 서비스 ] ↔ [ 결제 서비스 ]  
# 설명: 양방향 협력 관계 (파트너십)

👉 특징:

• 한쪽 변경이 다른 쪽에 직접적인 영향을 미침.
• 팀 간 긴밀한 협업 필요.

---

2. 공유 커널 (Shared Kernel)

예제:

🔍 "회원 서비스와 인증 서비스가 동일한 사용자 정보 DB를 공유"

• 회원 서비스와 인증 서비스는 사용자 정보 모델(User Entity)을 공유하며, 동일한 DB 테이블을 사용한다.
• 양측 서비스는 이 모델을 변경할 때 반드시 조율해야 한다.

📌 컨텍스트 맵 표현:

[ 회원 서비스 ] - - - (공유 커널) - - - [ 인증 서비스 ]  
# 설명: 회원 정보 데이터 모델을 공유

👉 특징:

• 공유되는 코드나 데이터가 존재.
• 독립성이 약하며 변경 시 조율 필요.

---

3. 고객-공급자 (Customer-Supplier)

예제:

🛒 "주문 서비스(Customer)와 결제 서비스(Supplier)의 관계"

• 주문 서비스는 결제 서비스를 사용하여 결제를 처리해야 한다.
• 결제 서비스가 API를 변경하면 주문 서비스는 이를 반영해야 한다.

📌 컨텍스트 맵 표현:

[ 주문 서비스 ] → [ 결제 서비스 ]  
# 설명: 주문 서비스가 결제 서비스의 API를 소비하는 고객 역할

👉 특징:

• 고객(Customer)은 공급자(Supplier)의 API를 사용.
• 공급자는 고객을 고려하여 API 설계 및 버전 관리를 수행.

---

4. 순응자 (Conformist)

예제:

🎶 "음원 스트리밍 서비스가 외부 음원 제공사의 데이터를 그대로 따르는 경우"

• 음원 스트리밍 서비스는 여러 음원 제공사로부터 데이터를 받지만, 제공사의 포맷을 그대로 사용한다.
• 즉, 자체적인 데이터 변환 없이 공급자의 포맷을 따름.

📌 컨텍스트 맵 표현:

[ 음원 스트리밍 서비스 ] →→ [ 음원 제공사 API ]  
# 설명: 공급자의 포맷을 그대로 따름 (Conformist)

👉 특징:

• 공급자가 주도하며, 고객은 따름.
• 고객은 공급자의 API 및 데이터 모델 변경에 종속됨.

---

5. 공개 호스트 서비스 (Open Host Service)

예제:

🌍 "OAuth 기반 인증 서비스"

• OAuth 인증 서버는 여러 클라이언트(웹/모바일 앱)가 공통 프로토콜을 사용하여 접근 가능하도록 한다.
• 특정 기업뿐만 아니라 모든 외부 개발자가 접근할 수 있도록 공개 API 제공.

📌 컨텍스트 맵 표현:

                [ OAuth 인증 서버 ]  
                      ↑      
      — — — — — — — — — — — —      
      |          |          |        
 [ 웹 앱 ]  [ 모바일 앱 ]  [ 서드파티 앱 ]  
# 설명: OAuth 서버가 여러 클라이언트에 서비스 제공 (Open Host Service)

👉 특징:

• 표준화된 API 또는 프로토콜을 통해 다수의 클라이언트가 사용.
• 새로운 클라이언트 추가가 용이함.

---

6. 반부패 계층 (Anticorruption Layer, ACL)

예제:

🏦 "내부 결제 시스템과 외부 금융 서비스 연계"

• 내부 결제 서비스는 외부 금융 시스템의 데이터를 직접 사용하지 않고, 변환 계층(ACL)을 거쳐 사용한다.
• ACL이 중간에서 데이터 변환 및 오류 처리 등을 수행.

📌 컨텍스트 맵 표현:

[ 내부 결제 시스템 ] → (ACL) → [ 외부 금융 API ]  
# 설명: ACL을 통해 외부 API 데이터를 내부 모델에 맞게 변환

👉 특징:

• 외부 시스템의 복잡한 구조를 숨기고, 내부 모델과의 간극을 줄임.
• 외부 API 변경에 대한 영향 최소화.

---

WRAP-UP ^{결어/종합/대안}

📌 정리

컨텍스트 간 관계를 컨텍스트 맵에서 표현하는 방법을 정리하면 다음과 같습니다.

관계 유형	예제	컨텍스트 맵 표현 방식
파트너십	배달 서비스 ↔ 결제 서비스	양방향 연결 (↔)
공유 커널	회원 서비스 - 인증 서비스	점선 (- - -)
고객-공급자	주문 서비스 → 결제 서비스	단방향 화살표 (→)
순응자	음원 스트리밍 서비스 →→ 음원 제공사	두꺼운 화살표 (→→)
공개 호스트 서비스	OAuth 인증 서버 ↑ 여러 클라이언트	중앙 서비스에서 다수 연결
반부패 계층 (ACL)	내부 결제 시스템 → (ACL) → 외부 금융 API	중간 ACL 계층 추가

 

2025.04.02.
AUDITORIS