Blog
Bounded Context: 도메인 모델의 경계를 정의하는 핵심
이 글에서는 Bounded Context의 개념과 역할을 확인하고, 도메인 경계를 효과적으로 정의하는 방법을 제공합니다.
2025년 02월 21일
Bounded Context: 도메인 모델의 경계를 정의하는 핵심
Bounded Context는 도메인 주도 설계(DDD)의 핵심 개념 중 하나로, 특정 도메인 모델이 의미를 가지는 경계를 정의합니다. 이는 복잡한 비즈니스 시스템을 이해하고 관리하기 쉽게 만들어주는 중요한 도구입니다.
Bounded Context란 무엇인가요?
Bounded Context(경계를 가진 문맥)는 도메인 주도 설계(DDD, Domain-Driven Design)에서 핵심 개념 중 하나로, 특정 도메인의 개념과 의미를 명확하게 정의하는 경계(boundary)를 의미합니다. Bounded Context를 이해하는 것은 마치 건물을 짓기 전에 각 층과 방의 역할을 정의하는 것과 같습니다. 각각의 Bounded Context는 특정 비즈니스 영역에 집중하고, 내부적으로는 일관성을 유지하며, 외부와의 상호작용은 명확하게 정의된 방식으로 이루어집니다.
Bounded Context의 예시
- 소프트웨어 개발에서는 같은 용어가 다르게 해석될 가능성이 크다. 예를 들어, “상품(Product)”이라는 개념이 “주문 시스템(Order System)“과 “재고 관리 시스템(Inventory System)“에서 각각 다른 의미를 가질 수 있다.
- 주문 시스템에서는 “상품”이 고객이 구매한 항목을 의미한다.
- 재고 관리 시스템에서는 “상품”이 창고에서 보관 중인 물리적 아이템을 의미한다.
- 자상거래 시스템에서 “고객(Customer)” 개념이 다른 문맥에서 어떻게 달라지는지 살펴봅니다.
| Bounded Context | Customer의 의미 | 특징 |
|---|---|---|
| 주문 시스템 (Order System) | 주문을 한 고객 | 고객의 주문 내역을 관리 |
| 마케팅 시스템 (Marketing System) | 이메일을 받아볼 수 있는 고객 | 광고 캠페인, 이메일 마케팅 대상 |
| 고객 서비스 시스템 (Customer Support) | 상담 이력이 있는 고객 | 고객 문의 및 지원 요청 기록 |
- 이처럼 각 시스템에서 “Customer”라는 개념이 다르게 정의되므로 서로 다른 문맥(Context)에서 의미가 달라질 수 있습니다.
- 이러한 개념적 충돌을 방지하고 명확한 경계를 설정하는 것이 Bounded Context의 핵심 목적이다.
Bounded Context와 이벤트 스토밍, 컨텍스트 매핑의 관계 및 진행 방법
1. 개념 간 관계
이벤트 스토밍으로 컨텍스트를 찾고, Bounded Context로 서비스 경계를 정의한 뒤, 컨텍스트 매핑을 통해 서비스 간의 상호작용을 정리하는 방식으로 진행된다. 이 과정을 거치면 MSA에서 서비스 간의 역할과 관계가 명확해지고, 향후 확장성과 유지보수성이 향상된다.
- Bounded Context(경계 컨텍스트)는 도메인 모델을 독립적인 경계 내에서 관리할 수 있도록 정의하는 개념이다. 이는 MSA에서 서비스 분리를 결정하는 핵심 개념이다.
- 이벤트 스토밍(Event Storming)은 도메인 이벤트를 중심으로 도메인을 탐색하고, 비즈니스 프로세스를 모델링하는 기법이다. 이를 통해 Bounded Context의 후보를 찾을 수 있다.
- 컨텍스트 매핑(Context Mapping)은 여러 Bounded Context 간의 관계를 정의하는 기법이다. 즉, 이벤트 스토밍을 통해 Bounded Context를 도출한 후, 컨텍스트 매핑을 통해 이들이 상호작용하는 방식과 의존성을 정의하게 된다.
| 단계 | 역할 | 주요 활동 |
|---|---|---|
| 1. 이벤트 스토밍 | Bounded Context 후보 도출 | – 주요 이벤트 식별 – 애그리게잇 및 도메인 개념 정의 – 서비스 분리 기준 찾기 |
| 2. Bounded Context 정의 | 독립적 도메인 및 서비스 결정 | – 도메인 모델 확정 – 데이터 모델 및 API 설계 – 내부 비즈니스 로직 정의 |
| 3. 컨텍스트 매핑 | 서비스 간 관계와 협력 방식 정의 | – 서비스 간 상호작용 정의 – 관계 패턴 적용 (Customer -Supplier, ACL 등) – API 및 데이터 공유 방식 결정 |
2. 진행 절차 및 역할
1) 이벤트 스토밍: Bounded Context를 식별하는 과정
-
- 핵심 도메인 전문가(도메인 전문가, 개발자, 기획자 등)들이 함께 참여하여 도메인 이벤트를 중심으로 논의한다.
- 주요 이벤트(예: 주문 생성, 결제 승인, 배송 시작)를 식별하고, 이를 기반으로 애그리게잇(Aggregate)과 역할을 정의한다.
- 이벤트 간 연관성을 분석하면서 자연스럽게 서비스를 어디서 분리할지, 즉 Bounded Context의 경계를 결정할 수 있다.
2) Bounded Context 정의: 서비스 및 도메인 책임 결정
-
- 이벤트 스토밍에서 식별한 애그리게잇과 도메인 개념을 기반으로 각 컨텍스트의 역할과 책임을 구체화한다.
- 컨텍스트 내에서 데이터 모델, API 설계, 내부 비즈니스 로직 등을 설계할 수 있다.
3) 컨텍스트 매핑: Bounded Context 간 관계 정의
-
- Bounded Context가 하나의 독립된 서비스나 시스템이 되는 것이 아니라, 서로 협력하거나 의존하는 관계를 갖는다.
- 이를 명확하게 정리하기 위해 컨텍스트 매핑을 수행하며, 다음과 같은 패턴을 적용할 수 있다.
- Shared Kernel: 일부 핵심 모델을 공유
- Customer-Supplier: 한 컨텍스트가 다른 컨텍스트의 출력에 의존
- Anti-Corruption Layer: 다른 컨텍스트와의 직접적인 의존을 막기 위해 변환 계층 적용
- Open Host Service: 공통 API를 제공하여 여러 컨텍스트가 동일한 인터페이스를 활용
3. 실무 적용 예시
예를 들어, 전자상거래 시스템을 MSA로 분리한다고 하면, 다음과 같은 절차를 따른다.
1) 이벤트 스토밍을 수행
-
- “주문이 생성됨”, “결제가 승인됨”, “배송이 시작됨” 등의 주요 이벤트를 나열
- 이를 기준으로 관련 애그리게잇(예: 주문, 결제, 배송)을 정의
- 여기서 자연스럽게 주문 서비스, 결제 서비스, 배송 서비스 같은 Bounded Context를 도출
2) Bounded Context를 확정하고 서비스 분리
-
- 주문 서비스: 주문 생성 및 상태 관리
- 결제 서비스: 결제 승인 및 취소 처리
- 배송 서비스: 배송 요청 및 진행 상황 관리
3) 컨텍스트 매핑을 통해 관계 정의
-
- 주문 서비스는 결제 서비스와 Customer-Supplier 관계 (주문이 결제 승인 여부에 따라 진행)
- 배송 서비스는 주문 서비스의 이벤트를 구독하는 구조
- 결제 서비스와 주문 서비스 사이에 Anti-Corruption Layer를 적용하여 결제 시스템 변경 영향을 최소화
Bounded Context 관련 주요 개념 및 이론
Bounded Context를 깊이 이해하기 위해 중요한 개념들을 정리하였습니다. 이를 숙지하면 도메인 주도 설계(DDD)와 마이크로서비스 아키텍처(MSA)에서의 Bounded Context 개념을 보다 효과적으로 적용할 수 있습니다.
| 개념 | 설명 |
|---|---|
| 유비쿼터스 언어 | Bounded Context 내에서 개발자와 비즈니스 담당자가 사용하는 공통 언어 |
| 애그리게잇 | 관련 엔티티와 값 객체를 묶어 일관성을 유지하는 단위 |
| 도메인 이벤트 | 도메인에서 발생한 중요한 상태 변화를 알리는 이벤트 |
| Upstream-Downstream 관계 | 컨텍스트 간 변화의 방향성을 정의하는 개념 |
| Anti-Corruption Layer | 컨텍스트 간 데이터 변환 및 보호 계층 |
| 폴리글랏 퍼시스턴스 | 컨텍스트별로 최적화된 데이터 저장소를 선택하는 전략 |
1. 유비쿼터스 언어 (Ubiquitous Language)
Bounded Context 내에서 도메인 전문가와 개발자가 공통으로 사용하는 언어입니다. 유비쿼터스 언어를 통해 팀원 간 의사소통을 명확하게 하고, 비즈니스 로직을 보다 정확하게 이해할 수 있습니다. 일관된 용어를 사용함으로써 개발 과정에서 발생할 수 있는 오해를 줄이고, 코드와 비즈니스 개념 간의 불일치를 방지할 수 있습니다.
예제) 전자상거래 시스템을 개발할 때, ‘주문(Order)’이라는 용어가 다양한 의미로 사용될 수 있다.
- 영업팀: 고객이 상품을 요청한 행위
- 물류팀: 배송이 필요한 물품의 리스트
- 회계팀: 매출이 발생한 기록
이처럼 같은 개념이 다른 의미로 사용될 수 있으므로, Bounded Context 내에서 ‘주문’이라는 용어를 정확하게 정의해야 한다. 예를 들어, “주문(Order)은 고객이 상품을 구매할 때 생성되는 비즈니스 트랜잭션이며, 주문 상태(Order Status)를 통해 진행 과정을 추적한다”라는 식으로 명확히 정의하면 혼선을 줄일 수 있다.
2. 애그리게잇 (Aggregate)
Bounded Context 내에서 데이터와 로직을 그룹화하는 개념으로, 하나의 트랜잭션 단위가 됩니다. 애그리게잇은 관련된 엔티티(Entity)와 값 객체(Value Object)들을 포함하며, 외부에서 접근할 수 있는 단일 진입점인 애그리게잇 루트(Aggregate Root)를 가집니다.
예제) “주문(Order)” 애그리게잇
“주문(Order)” 애그리게잇은 “주문 항목(Order Item)”을 포함하며, 외부에서는 주문 객체를 통해서만 주문 항목을 관리할 수 있습니다. 이를 통해 데이터 일관성을 유지하고, 내부 복잡성을 효과적으로 감출 수 있습니다.
3. 도메인 이벤트 (Domain Event)
도메인 내에서 중요한 상태 변화가 발생했음을 알리는 개념입니다. 예를 들어, “주문이 생성됨(Order Created)”, “결제가 완료됨(Payment Completed)” 등의 이벤트가 존재할 수 있습니다.
도메인 이벤트는 비동기적으로 다른 컨텍스트에 전달될 수 있으며, 이벤트 기반 아키텍처에서 중요한 역할을 합니다. 이를 활용하면 서비스 간 결합도를 낮추고, 확장성을 높일 수 있습니다.
4. 컨텍스트 간 관계 및 통합 방법
- Upstream-Downstream 관계 : Bounded Context 간 상호작용에서 한 컨텍스트가 다른 컨텍스트에 영향을 미치는 방향성을 나타냅니다.
- Upstream 컨텍스트: 변화를 주도하는 컨텍스트
- Downstream 컨텍스트: Upstream의 변경 사항을 따라가야 하는 컨텍스트
- 예를 들어, “상품 카탈로그(Product Catalog)”가 변경되면, 이를 참조하는 “주문 시스템(Order System)”도 영향을 받을 수 있습니다.
- Anti-Corruption Layer (ACL) : 서로 다른 컨텍스트 간의 영향을 최소화하기 위한 계층입니다.
- 데이터 변환 및 API 어댑터 역할 수행
- 외부 시스템의 변경이 내부 시스템에 직접적인 영향을 주지 않도록 보호
- 예를 들어, 외부 결제 시스템이 JSON API를 제공하지만 내부 시스템에서는 XML을 사용해야 하는 경우, ACL을 통해 데이터를 변환하여 시스템 간의 충돌을 방지할 수 있습니다.
5. 폴리글랏 퍼시스턴스 (Polyglot Persistence)
각 Bounded Context가 최적화된 데이터 저장소를 선택하는 전략입니다.
- 관계형 데이터베이스 (RDB)
- NoSQL (MongoDB, Cassandra)
- 인메모리 데이터 저장소 (Redis)
예를 들어, 주문 관리 시스템은 트랜잭션을 보장하기 위해 **관계형 데이터베이스(RDB)**를 사용하고, 추천 시스템은 빠른 검색을 위해 NoSQL을 사용할 수 있습니다.
마무리
Bounded Context는 도메인 모델의 경계를 정의하고, 복잡한 시스템을 관리하기 쉽게 만들어주는 강력한 도구입니다. 이벤트 스토밍 워크샵과 컨텍스트 매핑을 통해 Bounded Context를 효과적으로 정의하고 관리할 수 있습니다.
또한 유비쿼터스 언어, 엔티티, 값 객체, 애그리거트, 도메인 이벤트, 폴리글랏 퍼시스턴스 등과 같은 추가적인 개념을 이해하면, Bounded Context를 더욱 깊이 있게 이해하고 활용할 수 있습니다.
