이제부터는 기획 문서를 도메인 언어로 바꾸는 단계입니다. 01장에서 우리는 왜 이 서비스를 만들고, 누가 어떤 시나리오를 수행하며, 무엇을 MVP로 삼을지 정했습니다. 하지만 그 문장만으로는 아직 코드 구조가 나오지 않습니다. DDD로 넘어가려면 먼저 팀이 같은 말을 쓰고, 그 말이 실제 상태 변화와 어떤 순서로 연결되는지를 드러내야 합니다.
이 페이지의 목적은 두 가지입니다. 첫째, 이 프로젝트에서 반복해서 사용할 핵심 용어를 고정하는 것입니다. 둘째, 그 용어가 실제 서비스 흐름에서 어떤 이벤트로 나타나는지 보이게 만드는 것입니다. 이 두 작업이 없으면 뒤에서 바운디드 컨텍스트를 자를 때 사람마다 다른 기준을 들고 오게 됩니다.
DDD에서 가장 흔한 실패는 복잡한 설계 기법을 먼저 가져오는 것입니다. 애그리거트, 리포지토리, 도메인 서비스 같은 단어를 빨리 쓰기 시작하면, 정작 무엇을 모델링하고 있는지 놓치기 쉽습니다.
실제 문제는 훨씬 단순합니다. 팀 안에서 같은 단어를 서로 다르게 쓰는 순간, 모델은 바로 흔들립니다.
예를 들어 아래 표현을 생각해 봅시다.
주문 생성결제 완료구매 완료주문 확정이 네 표현이 같은 뜻인지, 다른 뜻인지가 정리되지 않으면 큰 문제가 생깁니다.
order_confirmed를 쓰고 어떤 화면은 paid를 쓴다즉 유비쿼터스 언어는 보기 좋은 용어집이 아니라, 시스템 혼선을 줄이는 최소 장치입니다.
용어만 정리해서는 아직 부족합니다. 용어는 정적인 목록이고, 서비스는 동적인 흐름이기 때문입니다.
이커머스는 상태가 계속 바뀌는 서비스입니다.
즉 이 서비스는 "무엇이 존재하는가"만이 아니라 "무엇이 언제 일어나는가"를 모델링해야 합니다. 이벤트 스토밍은 바로 그 흐름을 빠르게 드러내는 도구입니다.
이번 교재에서 이벤트 스토밍은 화려한 워크숍 기법이 아니라, 핵심 흐름을 놓치지 않기 위한 구조화된 메모 방식으로 이해하면 됩니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
이 문서가 정리되면, 다음 장에서 바운디드 컨텍스트를 자를 근거가 생깁니다.
유비쿼터스 언어는 기획자, 개발자, 디자이너, 운영자가 같은 대상을 같은 말로 부르는 규칙입니다. 중요한 점은 "있으면 좋은 공용 용어집"이 아니라 "코드와 문서와 대화에 같이 써야 하는 언어"라는 것입니다.
즉 아래가 모두 연결되어야 합니다.
이 다섯 가지가 따로 놀면 나중에 번역 비용이 계속 생깁니다.
먼저 이 서비스에서 중요한 명사를 뽑아야 합니다. 명사는 보통 "무엇을 다루는가"를 드러냅니다.
이번 이커머스 교재에서 핵심 명사는 아래와 같습니다.
이 명사들을 그냥 나열하는 것으로 끝내면 안 됩니다. 각각이 무엇을 뜻하는지 짧게 정의해야 합니다.
| 용어 | 이 교재에서의 뜻 |
|---|---|
| 상품 | 판매 대상이 되는 단일 아이템 |
| 카탈로그 | 상품을 탐색하기 위한 목록과 분류 체계 |
| 장바구니 | 구매자가 주문 전에 임시로 상품을 담아 두는 상태 |
| 주문 | 구매 의사가 확정되어 생성된 거래 단위 |
| 결제 | 주문에 대해 금액 승인이 시도되고 결과가 결정되는 과정 |
| 주문 상태 | 주문이 현재 어느 단계에 있는지를 나타내는 값 |
| 상담 문의 | 사용자가 상품/주문 관련 질문을 남기는 행위 또는 그 기록 |
이 정의가 중요한 이유는, 뒤에서 Cart, Order, Payment를 별도 경계로 볼지 판단할 때 기준이 되기 때문입니다.
명사가 대상을 보여 준다면, 동사는 상태 변화를 보여 줍니다. DDD에서 동사가 중요한 이유는 도메인 이벤트가 대부분 "무엇이 일어났다"는 동사형 서술로 드러나기 때문입니다.
이번 교재에서 중요하게 다뤄야 할 동사는 아래와 같습니다.
예를 들어:
이렇게 동사가 붙기 시작하면, 정적인 명사가 실제 흐름으로 변합니다.
DDD에서는 용어 충돌을 초반에 없애는 것이 중요합니다. 이번 이커머스 프로젝트에서 특히 헷갈리기 쉬운 표현은 아래와 같습니다.
이 둘을 같은 뜻으로 쓰면 안 됩니다.
이번 교재에서는 단순화할 수 있지만, 개념상 분리해서 보는 습관이 중요합니다.
상품과 재고는 관련 있지만 같은 개념이 아닙니다.
AI 기능에서는 특히 이 둘을 같게 보면 안 됩니다.
이제 용어를 흐름으로 바꿉니다. 이벤트 스토밍에서 가장 먼저 보는 것은 "무엇이 일어났는가"입니다. 이벤트는 보통 완료형 문장으로 적습니다.
예를 들면:
중요한 점은 이벤트가 화면 이름이 아니라는 것입니다. 이벤트는 "무엇이 발생했는가"를 말해야 합니다.
이제 실제 이커머스 MVP 기준으로 핵심 이벤트를 순서대로 정리합니다.
이 흐름만 봐도 Catalog -> Cart -> Order -> Payment라는 경계 힌트가 보이기 시작합니다.
이 흐름은 구매 흐름과 다릅니다. 운영자는 상품을 사지 않고 상태를 관리합니다. 따라서 같은 데이터를 보더라도 다른 언어와 관심사가 필요합니다.
이 흐름은 Support Assistant라는 별도 관심사를 드러냅니다.
이벤트를 나열하면 자연스럽게 질문이 생깁니다. 이 질문이 바로 설계의 시작입니다.
예를 들어:
이 질문을 초반에 드러내는 것이 중요합니다. DDD는 정답을 외우는 방법이 아니라, 이런 질문을 빨리 표면으로 끌어올리는 방법에 가깝습니다.
이 단계에서 바로 코드를 짜지는 않지만, 용어가 나중에 어떻게 반영될지는 미리 생각해 두어야 합니다.
예를 들면:
Cart는 장바구니를 담는 상태를 표현하는 모델이 된다OrderCreated 같은 이벤트 이름은 주문 생성 시점을 표현할 수 있다PaymentConfirmed와 PaymentFailed는 결제 결과를 분리해 나타낼 수 있다OrderStatus는 값 객체 또는 열거형으로 정리할 수 있다즉 유비쿼터스 언어는 나중에 변수명과 클래스명에 들어갈 후보이기도 합니다.
이 장을 따라 하는 학습자는 최소한 아래 수준의 용어표를 직접 만들어 두는 것이 좋습니다.
| 분류 | 용어 | 정의 |
|---|---|---|
| 상품 영역 | 상품 | 판매 대상 |
| 상품 영역 | 카탈로그 | 상품 탐색을 위한 목록과 분류 |
| 주문 영역 | 장바구니 | 주문 전 임시 보관 상태 |
| 주문 영역 | 주문 | 구매 의사가 기록된 거래 단위 |
| 결제 영역 | 결제 | 승인/실패가 결정되는 과정 |
| 운영 영역 | 주문 현황 | 운영자가 모니터링하는 주문 상태 집합 |
| 상담 영역 | 상담 문의 | 사용자가 남긴 질문 |
| 상담 영역 | 상담 전환 | 챗봇이 사람 개입이 필요하다고 넘기는 흐름 |
간단하게는 아래처럼 텍스트로 정리해도 충분합니다.
중요한 것은 완벽한 워크숍 형식을 흉내 내는 것이 아니라, 핵심 흐름을 놓치지 않는 것입니다.
이 다섯 가지 실수는 다음 장의 컨텍스트 분리에 바로 악영향을 줍니다.
이 페이지에서 우리는 기획 문장을 도메인 언어로 바꾸기 시작했습니다. 핵심 명사와 동사를 고정했고, 그 용어가 실제 서비스에서 어떤 이벤트 순서로 나타나는지를 확인했습니다. 이제 다음 페이지에서는 이 이벤트 흐름과 용어를 기준으로 바운디드 컨텍스트를 자르고, 각 경계가 어떤 책임을 가져야 하는지 정리합니다.
다음 페이지에서는 지금 정리한 용어와 이벤트를 바탕으로 Catalog, Cart, Order, Payment, Admin, Support Assistant 같은 바운디드 컨텍스트를 실제로 나눕니다.