이제 나도 MSA 전문가: 개념부터 실무까지

마이크로서비스 아키텍처에서 가장 어려운 과제는 무엇일까? 단순히 서비스를 여러 개로 나눈다고 해서 MSA가 완성되는 것은 아니다. 서비스 간의 경계를 올바르게 정의하지 않으면 오히려 운영 복잡도만 증가하고, 기대했던 유연성과 확장성이 무너질 수 있다. 결국, 핵심은 도메인 경계를 정확하게 식별하고 분할하는 것이다. 마치 건물을 지을 때, 각 층과 방을 구분하는 것처럼, MSA에서는 비즈니스 로직의 영역을 명확히 나누어야 합니다. 이때 등장하는 개념이 바로 **도메인 주도 설계(Domain-Driven Design, DDD)**와 그 핵심 요소인 Bounded Context입니다.

DDD는 소프트웨어 개발을 비즈니스 도메인 전문가와 개발자가 협력하여 진행해야 한다는 철학을 담고 있습니다. 2003년, 에릭 에반스(Eric Evans)는 그의 저서 “Domain-Driven Design: Tackling Complexity in the Heart of Software”에서 복잡한 소프트웨어 개발의 문제점을 해결하기 위한 방법론으로 DDD를 제시했습니다. DDD의 기본적인 목표는 비즈니스 도메인의 복잡성을 효과적으로 관리하고, 소프트웨어 설계가 실제 비즈니스 개념과 일치하도록 하는 것입니다. 당시의 소프트웨어 개발 방식은 비즈니스 로직과 기술적인 구현이 혼재되어 있어, 비즈니스 요구사항이 변화할 때마다 코드가 지나치게 복잡해지는 문제가 있었습니다. 이를 해결하기 위해 DDD는 비즈니스 개념을 중심으로 한 설계를 제안했고, 여기서 중요한 원칙이 바로 Bounded Context입니다.

DDD는 전체적인 설계 철학을 제공하고, Bounded Context는 시스템을 분할하는 기본 단위를 제공합니다. 이벤트 스토밍 워크샵은 Bounded Context를 식별하는 데 사용되며, 컨텍스트 매핑은 Bounded Context 간의 관계를 정의합니다. 이 네 가지 요소는 서로 밀접하게 연관되어 있으며, 조화로운 협력을 통해 복잡한 시스템을 효과적으로 설계하고 개발할 수 있도록 도와줍니다.

정리하면, DDD의 실천 과정은 먼저 이벤트 스토밍 워크샵을 통해 도메인 이벤트와 프로세스를 도출하고, 이를 바탕으로 각 Bounded Context를 정의합니다. 이후 컨텍스트 매핑을 통해 서로 다른 Bounded Context 간의 관계와 상호작용을 명확히 함으로써, 전체 시스템이 유기적으로 연결되고 효율적으로 운영될 수 있도록 합니다. 이와 같은 절차와 관계 설정은 복잡한 비즈니스 로직을 효과적으로 관리하며, 변화에 유연하게 대응할 수 있는 시스템 설계를 가능하게 합니다.

일반적인 구현 과정은 다음과 같습니다.

1.  DDD: DDD 철학을 기반으로 시스템 설계의 전체적인 방향을 설정합니다.

2. 이벤트 스토밍 워크샵: 이해관계자들과 함께 이벤트 스토밍 워크샵을 진행하여 업무 흐름을 이벤트 중심으로 매핑합니다. 이 과정에서 자연스러운 도메인 경계를 발견하고, Bounded Context를 식별할 수 있습니다.

3. Bounded Context 도출 및 정의 : 이벤트 스토밍 결과를 바탕으로 도출된 도메인 이벤트들을 분석하면, 시스템 내에서 서로 다른 비즈니스 영역이나 책임 범위가 식별됩니다. 이러한 영역들이 바로 Bounded Context로 구분되며, 각 Context 내에서는 도메인 모델과 용어가 일관되게 사용됩니다. Bounded Context는 서로 다른 모델이 공존할 수 있도록 경계를 명확히 설정하여, 시스템 간의 혼란을 방지하고 각 영역의 자율성을 보장합니다.

4. 컨텍스트 매핑: Bounded Context가 정의되면, 이들 간의 상호작용과 의존 관계를 명확히 하기 위해 컨텍스트 매핑을 진행합니다. 컨텍스트 매핑은 각 Context가 어떻게 협력하고, 데이터나 이벤트를 교환하며, 통합되는지를 시각적으로 표현함으로써 전체 시스템 아키텍처의 명확한 그림을 제공합니다. 이를 통해 경계 간의 인터페이스와 통합 전략, 그리고 잠재적인 협업 또는 충돌 영역이 식별되어, 체계적인 시스템 설계가 가능해집니다.

5. 반복: 필요에 따라 위의 단계를 반복하여 도메인 모델을 개선하고, 시스템 설계를 더욱 정교하게 만듭니다.

이벤트 스토밍은 도메인 이해를, Bounded Context는 분할을, 컨텍스트 매핑은 통합을 담당합니다.DDD는 이 세 요소를 종합하여 복잡성을 제어하고 유지보수성을 높이는 프레임워크 역할을 합니다. 이처럼 각 단계는 서로 연계되어 도메인 문제를 체계적으로 해결하는 데 기여합니다

대형 온라인 쇼핑몰에서는 여러 도메인이 존재합니다. 예를 들어, 주문 처리, 재고 관리, 배송 추적 등이 각각 별도의 비즈니스 요구를 가집니다.

1. 이벤트 스토밍 진행– 도메인 전문가와 개발자들이 모여 “주문 생성”, “결제 완료”, “배송 시작”, “배송 완료” 등의 이벤트를 도출합니다.– 커맨드(예: “주문 요청”, “결제 요청”)와 액터(예: “고객”, “판매자”)를 함께 식별합니다.

2. 애그리게이트 도출– 주문, 결제, 배송과 같이 서로 관련된 이벤트와 커맨드를 하나의 애그리게이트로 묶어 도메인 모델을 구체화합니다.

3. 바운디드 컨텍스트 정의– 주문 관리 컨텍스트: 주문 생성, 결제 처리, 주문 변경 등 주문 관련 모든 이벤트와 커맨드를 포함– 재고 관리 컨텍스트: 상품 재고, 입출고, 재고 부족 알림 등 재고 관련 로직 집중– 배송 추적 컨텍스트: 배송 상태, 위치 추적, 배송 완료 등 배송 관련 이벤트 처리

4. 컨텍스트 매핑 수행– 예를 들어 주문 관리 컨텍스트는 재고 관리 컨텍스트에서 상품 재고 정보를 받아야 하므로, 고객-공급자 관계를 설정합니다.– 배송 추적 컨텍스트는 주문 관리 컨텍스트의 주문 상태 변화를 기반으로 배송을 시작하거나 완료하는 이벤트를 수신합니다.

이처럼 각 컨텍스트는 독립적으로 일관된 모델을 유지하면서, 필요한 경우 인터페이스(API, 메시지 큐 등)를 통해 서로 통신하도록 설계됩니다.

바운디드 컨텍스트와 컨텍스트 매핑의 적용 사례는 ‘대형 온라인 쇼핑몰’ 외에도 자동차 렌트 서비스나 타이어 커머스 사례 등 다양한 실제 프로젝트에서 찾아볼 수 있습니다.

1. DDD는 도메인 모델과 유비쿼터스 언어를 기반으로 비즈니스 문제를 해결하는 설계 철학입니다.

2. 이벤트 스토밍은 도메인 내에서 발생하는 주요 사건(이벤트), 이를 유발하는 커맨드 및 액터, 그리고 관련 애그리게이트를 도출하는 협업 기법으로, 도메인 지식을 빠르게 공유하고 경계를 도출하는 데 효과적입니다.

3. 바운디드 컨텍스트는 도출된 모델이 적용되는 경계를 명확히 하여 모델의 일관성과 독립성을 보장하며,

4. 컨텍스트 매핑은 여러 바운디드 컨텍스트 간의 상호작용과 의존 관계를 정의하여 전체 시스템의 통합을 효과적으로 관리합니다.

실제 사례로 대형 온라인 쇼핑몰에서는 주문, 재고, 배송 등 각기 다른 도메인을 바탕으로 이벤트 스토밍을 진행하여 각 영역을 바운디드 컨텍스트로 구분하고, 이를 컨텍스트 매핑을 통해 서로 협력할 수 있도록 설계함으로써 시스템의 확장성과 유지보수성을 높일 수 있었습니다.

DDD의 실천 과정은 먼저 이벤트 스토밍 워크샵을 통해 도메인 이벤트와 프로세스를 도출하고, 이를 바탕으로 각 Bounded Context를 정의합니다. 이후 컨텍스트 매핑을 통해 서로 다른 Bounded Context 간의 관계와 상호작용을 명확히 함으로써, 전체 시스템이 유기적으로 연결되고 효율적으로 운영될 수 있도록 합니다. 이와 같은 절차와 관계 설정은 복잡한 비즈니스 로직을 효과적으로 관리하며, 변화에 유연하게 대응할 수 있는 시스템 설계를 가능하게 합니다.