Architecture - 컨텍스트 통합을 위한 매핑 전략
in DEV on Architecture, DDD
비즈니스의 다양한 전문 영역은 각기 고유한 바운디드 컨텍스트를 가지며, 이들은 팀마다 다른 방식으로 모델링된다. 하지만 복잡한 시스템은 이러한 컨텍스트 간의 상호 작용을 피할 수 없는데 이 때 중요한 것이 컨텍스트 간 매핑이다.
이 포스트에서는 컨텍스트 간 통합을 위한 8가지 대표적인 매핑 전략을 소개하고, 실패를 초래하는 나쁜 모델링 사례와 성공으로 이끄는 설계 사례를 통해 어떻게 적절한 전략을 선택할 수 있는지 알아본다. 또한 실험과 발견 기반 도구를 이용하여 도메인 문제를 해결하는 방법까지 함께 알아본다.
<컨텍스트 매핑이 중요한 이유>
- 컨텍스트 간 협업은 필수
- 단일 시스템이 아니라 여러 팀과 하위 도메인이 얽힌 소프트웨어에서는 각 컨텍스트가 독립적으로 설계되더라도 통합은 불가피함
- 팀 간 관계를 명확히 이해해야 함
- 상호 신뢰, 권한, 의존성 수준에 따라 서로 다른 매핑 전략을 택해야 함
- 도구 이름보다 ‘언제, 왜, 어떻게’가 더 중요
- 매핑 전략의 이름보다는, 그것이 왜 필요하고 어떤 상황에 적절한 지 아는 것이 핵심
목차
- 1. 컨텍스트 매핑(Context Mapping)
- 2. 지형 모델링(Topography Modeling): 시스템 경계와 관계를 시각화하는 전략
- 3. 성공과 실패의 갈림길
- 참고 사이트 & 함께 보면 좋은 사이트
1. 컨텍스트 매핑(Context Mapping)
복잡한 소프트웨어에서 하나의 팀이 모든 도메인을 완벽히 이해하고 구현하는 것은 불가능하다.
이에 따라 바운디드 컨텍스트라는 경계가 생기고, 각 컨텍스트는 별도의 모델, 언어, 구현 방식으로 존재한다. 이 경계들 사이의 통합은 필연적이며, 이 때 필요한 것이 바로 컨텍스트 매핑이다.
여기서는 컨텍스트 매핑의 정의와 역할, 그리고 다양한 매핑 형태의 관계성에 대해 알아본다.
컨텍스트 매핑은 둘 이상의 바운디드 컨텍스트 간의 관계를 명시하고 관리하는 전략이다.
이 전략은 DDD 의 전략적 설계 개념의 핵심 요소 중 하나로 컨텍스트 간의 소통, 통합, 협업 방식을 시각화하고 명확하게 한다.
두 개의 바운디드 컨텍스트가 어떤 방식으로 소통하고 의존하는지 모델링한 것을 컨텍스트 맵이라고 한다.
컨텍스트 맵은 다양한 매핑 전략을 통해 표현되며, 팀 간 신뢰, 의존성, 협력의 깊이에 따라 그 형태가 달라진다.
컨텍스트 매핑 전략은 상호 배타적이지 않고 함께 적용될 수 있다.
예를 들어 파트너십을 형성한 두 팀이
- 모델의 일부를 공유 커널로 유지하면서,
- 동시에 데이터 통신을 위한 발행된 언어를 사용할 수 있음
1.1. 파트너십
1.1. 파트너십(Partnership) 패턴 을 참고하세요.
1.2. 공유 커널
1.2. 공유 커널(Shared Kernel) 패턴 을 참고하세요.
1.3. 고객-공급자 개발
2. 사용자-제공자(Customer-Supplier) 패턴 그룹 을 참고하세요.
1.4. 순응주의자
2.1. 순응주의자(Conformist) 패턴 을 참고하세요.
1.5. 부패 방지 계층
1.6. 오픈 호스트 서비스
2.3. 오픈 호스트 서비스(OHS: Open-Host Service) 패턴: 외부 연동을 위한 개방형 전략 을 참고하세요.
1.7. 발행된 언어
1.8. 분리된 방식
2. 지형 모델링(Topography Modeling): 시스템 경계와 관계를 시각화하는 전략
DDD 에서 바운디드 컨텍스트를 정의하는 것은 필수적인 작업이지만, 현실에서는 그 경계를 명확하게 식별하기가 어렵다. 특히 이벤트 스토밍을 진행하다보면, 비즈니스 역량 중심의 자연스러운 경계 설정이 쉽지 않은 경우가 많다.
이 때 지형 모델링은 컨텍스트 간의 관계와 경계를 더욱 직관적이고 명확하게 시각화할 수 있는 전략적 도구로 유용하게 사용된다.
지형 모델링은 컨텍스트 간 관계와 정보 교환의 흐름을 지도처럼 시각화하여 경계를 식별하는 전략적 모델링 기법이다.
지형 모델링은 복잡한 시스템 안에서 비즈니스 역량 간의 자연스러운 경계와 상호작용 흐름을 이해하는데 큰 도움을 준다.
특히 DDD 실천 초기에 팀 간 설계 충돌이나 협업 경로를 파악하는데 매우 효과적이다.
- 아키텍처 세부 정보를 생략하고, 경계와 상호작용에 집중
- 이벤트 스토밍 이후, 경계를 흐리게 하는 상호작용 패턴을 시각적으로 식별하는데 활용
- 컨텍스트 맵의 보완 도구로 사용됨
<지형 모델링을 활용하는 상황>
| 상황 | 설명 |
|---|---|
| 이벤트 스토밍 중 경계 식별이 불분명할 때 | 이벤트 흐름은 있는데 경계가 흐릿한 경우 |
| 컨텍스트 간 커뮤니케이션이 빈번한 경우 | 상호작용 구조가 복잡하여 의존성이 얽혀있음 |
| 통합 전략 수립 이전에 관계 구조를 파악할 필요가 있을 때 | 충돌 방지 기법, 오픈 호스트 서비스 도입 전 선행 분석 단계로 적합 |
<지형 모델링 구성 요소>
- 컨텍스트 중심의 지도
- 각 팀 또는 바운디드 컨텍스트를 하나의 지형 단위로 표현
- 물리적 위치가 아니라 의사소통과 연동의 흐름 중심으로 배치
- 정보 흐름 시각화
- 쿼리, 커맨드, 이벤트 등을 화살표로 시각화
- 단방향/양방향 관계, 의존성의 강도 등을 표현 가능
- 중간 계층, API, 이벤트 채널 등의 표현
- 충돌 방지 계층, AGW, 메시지 브로커 등도 지형에 표시
- 어떤 통로를 통해 연동되는지 명확하게 드러남
<실제 워크숍에서 활용법>
- 각 팀이 자신의 컨텍스트를 정의
- 내부 도메인, 주요 액터, 핵심 책임을 중심으로 구성
- 상호 연동하는 컨텍스트를 외곽에 배치
- 이벤트 발신자, 소비자, API 호출자 등
- 화살표로 연동 경로 표시
- 커맨드: 실선
- 쿼리: 점선
- 이벤트: 이중선
- 불분명한 경계, 의존성 충돌 지점 식별
- 이 지점이 바로 충돌 방지 계층 또는 오픈 호스트 서비스 도입의 후보
- 다시 팀 내부로 가져와 통합 전략 재설계에 활용
- 어느 지점에 연동이 과도한가?
- 어느 경계에서 순응주의자 패턴이 발생하고 있는가?
<지형 모델링의 기대 효과>
- 경계 식별 명확화
- 비즈니스 역량이 어디까지 영향을 미치는지 명확히 드러남
- 팀 이해도 향상
- 자신의 위치와 주변과의 관계를 시각적으로 인식
- 통합 전략 설계 기반
- 충돌 방지 계층, 오픈 호스트 서비스, 공표된 언어 설계의 선행 자료로 활용 가능
3. 성공과 실패의 갈림길
DDD 는 단순한 기술 접근이 아니다.
학습과 전략적 발견, 커뮤니케이션 구조에 대한 깊은 이해가 전제되어야 성공할 수 있다.
실패는 그 자체로도 값진 학습의 기회가 될 수 있다. 하지만 조직은 무한히 실패를 감내할 수는 없다. 따라서 회피 가능한 실패를 미리 인지하고 피하는 것이 중요하다.
특히 DDD 에서 흔히 발생하는 실수는 대부분 “전략적 학습 부족” 또는 “기술 중심 사고” 에서 비롯된다.
3.1. 피해야 할 실패 유형들
- 전략적 학습을 하지 않는다.
- 단순히 기술만 도입하고 전략적 발견과 학습을 무시한다면 DDD 는 껍데기에 불과하다
- 결과적으로 기존 개발 방식과 전혀 다를 바 없는 결과가 만들어진다.
- 너무 많은 것을 너무 빨리 한다.(조급한 구현)
- 성급한 코딩과 컨텍스트 분리 시도는 피상적인 설계로 이어지고,
- 비즈니스 중심의 고민없이 기술 솔루션에만 매달리게 된다.
- DDD 는 ‘빨리 만드는 기술’이 아니라 ‘제대로 문제를 이해하고 설계하는 방법’이다.
- 강한 커플링과 시간 종속성
- REST API 나 RPC(Remote Procedure Call) 중심의 통합은 시간과 데이터에 대한 강한 결합을 초래한다.
- 이로 인해 업스트림의 변경이 전체 시스템에 파급 효과를 준다.
- 종속성 관리를 고려하지 않은 통합은 시스템 유연성을 크게 해친다.
- 광범위한 데이터 복제
- 데이터를 임의로 복제하여 사용하면, 원본 데이터에 대한 권한과 소유 개념이 흐려지게 된다.
- 시간이 지나면 데이터가 잘못 사용되거나 오남용될 가능성이 커진다.
- 기술 중심의 실패(도메인을 이해하지 못한 채 기술 설계 진행)
- 모델의 불일치, 과도한 추상화 계층, 유비쿼터스 언어의 변형 등이 발생한다.
- 미래의 미지의 요구에 대비하기 위해 매우 추상적인 유형의 계층 구조를 추구할 수 있지만, 장기적으로 그 결정이 올바른 것으로 입증되는 경우는 거의 없다.
- 숙련되지 않은 개발자가 투입되거나, 불필요한 아키텍처 욕심이 개입될 때 자주 발생한다.
- 기술은 전략에 종속되어야 하며, 목적이 아니라 수단임을 잊지 말아야 한다.
3.2. 성공에 가까워지는 전략
- 비즈니스 목표를 명확히 한다.(방향성과 유연성 확보)
- 현재 알고 있는 정보 기반으로 시작하되, 새로운 인사이트가 생기면 유연하게 방향을 바꿀 수 있어야 한다.
- 전략적 학습 도구를 활용한다.(도메인 이해 증진)
- 느슨한 커플링과 낮은 시간 종속성을 추구한다.(유연한 구조 유지)
- 바운디드 컨텍스트 간에는 서로에 대해 알아야 할 것이 적을수록 좋다.
- 컨텍스트 간 호출이나 동기화가 줄어들수록 시스템은 더 유연하고 독립적으로 진화할 수 있다.
- 데이터 소유권과 출처를 존중한다.(안정적인 시스템 운영)
- 데이터는 원본 위치에서 사용되고, 무단 복제나 임시 접근은 철저히 제한되어야 한다.
- 소유권의 개념이 설계에 반영되어야, 조직 내 데이터 신뢰성을 유지할 수 있다.
- 단순함을 추구하는 전술적 도구 선택(과한 설계 방지)
- 고비용의 설계나 복잡한 기술 도입은 명확한 비즈니스 필요성 없이는 피해야 한다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 반 버논, 토마스 야스쿨라 저자의 전략적 모놀리스와 마이크로서비스를 기반으로 스터디하며 정리한 내용들입니다.
