앞 페이지에서 우리는 유비쿼터스 언어와 이벤트 흐름을 정리했습니다. 이제 해야 할 일은 그 흐름을 경계로 자르는 것입니다. DDD에서 가장 중요한 질문 중 하나는 "무엇을 모델링할 것인가"가 아니라 "어디까지를 하나의 모델로 볼 것인가"입니다.
이커머스 서비스는 한 덩어리처럼 보이지만, 실제로는 서로 다른 관심사가 동시에 존재합니다. 상품을 탐색하는 문제와 주문을 생성하는 문제는 다르고, 결제를 처리하는 문제와 운영자가 상태를 모니터링하는 문제도 다릅니다. AI 상담 챗봇은 더 다릅니다. 이 차이를 무시하고 하나의 거대한 모델로 구현하면 처음에는 빨라 보여도, 곧 코드와 용어와 책임이 서로 엉키기 시작합니다.
이 페이지의 목적은 이 서비스의 경계를 명확히 나누는 것입니다. 어떤 도메인을 Catalog로 보고, 무엇을 Cart와 Order로 분리할지, Payment를 왜 따로 두는지, Admin과 Support Assistant가 왜 별도 컨텍스트가 되는지를 분명히 정해야 뒤의 애그리거트 설계와 API 설계가 안정됩니다.
DDD에서 바운디드 컨텍스트는 같은 용어가 동일한 의미를 갖는 경계입니다. 이 말은 반대로, 경계를 넘으면 같은 단어도 뜻이 달라질 수 있다는 뜻입니다.
예를 들어 주문 상태라는 표현을 생각해 봅시다.
겉으로는 모두 주문 상태처럼 보이지만, 관심사와 해석이 다릅니다. 이 차이를 무시하면 한 모델에 너무 많은 책임을 넣게 됩니다.
바운디드 컨텍스트가 필요한 이유는 세 가지입니다.
즉 컨텍스트 분리는 철학이 아니라 유지보수 비용을 낮추는 실제 기술 선택입니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
다음 장의 애그리거트 설계는 이 문서가 기준이 됩니다.
이번 교재에서는 아래 여섯 개 컨텍스트를 중심으로 모델을 나눕니다.
CatalogCartOrderPaymentAdminSupport Assistant필요하다면 인증이나 사용자 계정을 별도 Identity 컨텍스트로 분리할 수도 있지만, 이번 교재의 MVP에서는 Auth/User를 구현 레벨에서 다루되, 핵심 비즈니스 분리는 위 여섯 개를 기준으로 생각해도 충분합니다.
이제 각 컨텍스트를 하나씩 설명합니다.
Catalog는 상품을 탐색하고 이해하기 위한 컨텍스트입니다.
Catalog의 핵심 문제는 "무엇을 살 것인가"입니다. 아직 구매 의사만 형성되는 단계이며, 주문과 결제의 책임까지 가져오면 모델이 무거워집니다.
즉 상품을 보여주는 것과 실제 구매 상태를 관리하는 것은 분리해야 합니다.
Cart는 구매자의 임시 구매 의사를 관리하는 컨텍스트입니다.
Catalog와 분리하는가상품을 보여주는 문제와 장바구니 상태를 유지하는 문제는 다릅니다.
Catalog는 읽기 중심이다Cart는 사용자별 상태 변경 중심이다같은 상품 데이터를 쓰더라도 관심사가 다르기 때문에 별도 경계가 필요합니다.
Order와도 분리하는가장바구니는 아직 임시 상태입니다. 주문은 비즈니스적으로 기록된 거래 단위입니다. 이 둘을 같은 것으로 보면 "장바구니가 주문이 되는 순간"을 설명하기 어려워집니다.
Order는 구매 의사가 공식 거래로 기록되는 컨텍스트입니다.
Payment와 분리하는가가장 흔한 설계 실수는 주문과 결제를 하나의 모델로 묶는 것입니다. 하지만 이 둘은 다릅니다.
이번 교재에서는 단순화된 결제 흐름을 쓰더라도 개념상 분리는 유지해야 합니다.
Payment는 결제 승인과 실패 결과를 다루는 컨텍스트입니다.
결제는 외부 시스템과의 경계이기 때문입니다. 실제 PG를 붙이지 않더라도 개념상 외부 액터가 개입합니다. 따라서 Order 안에 흡수해 버리면 외부 연동과 실패 처리 모델이 흐려집니다.
Admin은 운영자가 서비스 상태를 관찰하고 관리하는 컨텍스트입니다.
운영자는 구매자가 아닙니다. 같은 주문 데이터를 보더라도 목적이 다릅니다.
같은 Order 정보를 읽더라도 질문이 다르기 때문에 읽기 모델과 관심사도 달라집니다.
Support Assistant는 AI 상담과 FAQ 응답 흐름을 다루는 컨텍스트입니다.
챗봇은 상품이나 주문을 직접 소유하지 않습니다. 대신 여러 컨텍스트의 읽기 정보를 가져와 질문에 맞게 조합합니다. 이 성격이 분명하기 때문에 Support Assistant는 자체 쓰기 모델보다 읽기 조합과 응답 정책이 중요한 컨텍스트가 됩니다.
텍스트로 먼저 그리면 아래처럼 볼 수 있습니다.
| 컨텍스트 | 주 관심사 | 주요 입력 | 주요 출력 |
|---|---|---|---|
| Catalog | 상품 탐색 | 상품 데이터 | 상품 목록, 상세 정보 |
| Cart | 임시 구매 상태 | 상품 선택, 사용자 행동 | 장바구니 상태, 합계 |
| Order | 거래 기록 | 장바구니 확정 | 주문 생성, 주문 상태 |
| Payment | 결제 결과 | 주문 금액, 결제 요청 | 승인/실패 결과 |
| Admin | 운영 모니터링 | 주문/상품 상태 | 운영 대시보드 정보 |
| Support Assistant | 상담 응답 | 질문, FAQ, 읽기 모델 | 챗봇 응답, 전환 제안 |
이 표만으로도 각 컨텍스트가 무엇을 소유하고 무엇을 소비하는지가 보이기 시작합니다.
이제 컨텍스트들이 어떻게 연결되는지 정리합니다.
구매자는 Catalog에서 상품을 탐색한 뒤 Cart에 담습니다.
중요한 점은 Cart가 상품 자체를 소유하지 않는다는 것입니다. 상품 정보의 원본은 Catalog에 있고, Cart는 주문 직전에 필요한 일부 스냅샷 또는 참조를 사용합니다.
장바구니 상태가 확정되면 Order가 생성됩니다.
이 순간이 중요한 이유는, 임시 상태가 거래 상태로 바뀌기 때문입니다. 따라서 Cart와 Order는 연결되지만 같은 모델이 아닙니다.
Order는 결제를 요청하고, Payment는 승인 또는 실패 결과를 반환합니다.
이 관계에서 핵심은 방향보다 역할입니다.
Order는 결제가 필요하다는 비즈니스 상황을 만든다Payment는 결제 처리 결과를 알려 준다즉 주문이 결제를 흡수하는 것이 아니라, 협력 관계를 가진다고 보는 편이 맞습니다.
운영자는 Admin에서 주문 상태를 읽습니다. 하지만 운영 화면은 Order와 동일한 모델을 그대로 보여주는 것이 아니라, 운영 목적에 맞는 읽기 모델로 재구성될 수 있습니다.
챗봇은 Catalog에서 상품 관련 정보, Order에서 주문 관련 정보를 읽어 응답합니다. 그러나 원본 데이터를 수정하지는 않습니다.
컨텍스트를 나누는 가장 큰 이유 중 하나는 데이터 주인을 명확히 하기 위해서입니다.
예를 들면:
CatalogCartOrderPaymentAdminSupport Assistant이렇게 정하지 않으면 같은 데이터를 여러 군데서 고치기 시작하고, 결국 상태 불일치가 생깁니다.
이커머스 초반 구현에서 흔히 "단순하게 하나로 가자"는 유혹이 있습니다. 하지만 그 비용은 곧바로 돌아옵니다.
결제 실패와 주문 실패를 같은 것으로 처리하기 시작합니다.
운영 대시보드용 필드와 예외 처리 로직이 주문 모델 내부로 들어오기 쉽습니다.
읽기 조합 컨텍스트여야 할 챗봇이 주문과 상품 모델을 직접 수정하려는 구조가 생길 수 있습니다.
결제 로직을 수정했는데 주문 API와 운영 화면과 챗봇 응답까지 같이 흔들리는 구조가 됩니다.
이번 교재는 학습용이지만, 컨텍스트 맵 사고방식은 실전형으로 가져갑니다.
즉:
Catalog, Cart, Order, Payment는 구매 흐름의 핵심 비즈니스 컨텍스트다Admin은 운영 관점의 읽기/관리 컨텍스트다Support Assistant는 읽기 조합과 응답 정책 컨텍스트다이 구분을 유지하면 이후에 서비스가 커져도 자연스럽게 확장할 수 있습니다.
이 장을 따라 하는 학습자는 아래 형식으로 직접 정리해 두는 것이 좋습니다.
이 다섯 가지 실수는 다음 장의 애그리거트 설계에서 더 큰 혼란으로 이어집니다.
이 페이지에서 우리는 이커머스 MVP를 여섯 개 핵심 컨텍스트로 나누고, 각 경계가 무엇을 책임져야 하는지 정리했습니다. 이제 모델은 훨씬 선명해졌습니다. 다음 페이지에서는 각 컨텍스트 안으로 더 들어가서 Aggregate, Entity, Value Object를 어떤 기준으로 설계할지 구체화합니다.
다음 페이지에서는 Catalog, Cart, Order, Payment 같은 컨텍스트 내부에서 어떤 애그리거트와 엔티티와 값 객체가 필요한지 구체적으로 정리합니다.