도메인 주도 설계 (Domain Driven Design - DDD)의 이벤트 스토밍 개념정리1

이벤트 스토밍 (Event Storming)

이벤트 스토밍은 Alberto Brandolini가 2013년에 고안한 워크숍 기반의 도메인 모델링 기법입니다. 복잡한 비즈니스 도메인을 빠르게 탐색하고 이해하기 위해 개발자, 도메인 전문가, 기획자, QA 등이 제품에 생산에 참여하는 사람들이 한자리에 모여 포스트잇으로 시스템의 흐름을 시각화하는 협업 방법론이죠.

핵심 아이디어

소프트웨어 시스템을 "도메인에서 일어나는 사건(Event)들의 흐름"으로 바라보는 것이 핵심입니다. 데이터베이스 테이블이나 클래스 다이어그램부터 시작하는 전통적인 방식과 달리, "무슨 일이 일어나는가?"라는 질문에서 출발합니다.

주요 구성 요소 (색상별 포스트잇)

워크숍에서는 보통 색깔별로 의미를 구분합니다.

• 🟧 Domain Event (주황색): "과거형"으로 표현되는 사건. 예: "주문이 생성됨", "결제가 완료됨", "PG사 응답이 수신됨"
• 🟦 Command (파란색): 이벤트를 발생시키는 행동/명령. 예: "주문 생성하기", "결제 요청하기"
• 🟨 Actor (노란색): 명령을 수행하는 주체 (사용자, 외부 시스템)
• 🟪 Aggregate (연보라색): 명령을 받아 이벤트를 발생시키는 도메인 객체
• 🟥 Hotspot/Issue (빨간색): 의문점, 충돌 지점, 결정이 필요한 사항
• 🟩 Policy (초록색): "이벤트가 발생하면 → 자동으로 명령 실행"의 규칙
• 🟫 Read Model (연한 노랑): 사용자가 의사결정을 위해 보는 화면/데이터

흐름은 보통 이렇게 연결 Actor → Command → Aggregate → Domain Event →  Policy → (다음 Command)

 

1 사이클 안에서는 사용자가 의도(Command)를 보내고, Aggregate가 비즈니스 규칙을 확인한 뒤 사실(Event)을 발생시킵니다. 여기까지가 한 단위

 

연속된 사이클은 Policy가 다리 역할을 합니다. "이런 Event가 발생하면 → 자동으로 저런 Command를 실행한다"는 규칙이 Policy이고, 이게 사이클과 사이클을 이어준다. 사용자가 매번 명령을 내리지 않아도 시스템이 자동으로 다음 단계를 진행할 수 있게 됩니다.

 

HOTSPOT이 추가된 이벤트 스토밍

Hotspot이 추가된 이벤트 스토밍

 

1. "중복 결제 방지는?" (Command 위)
사용자가 결제 버튼을 빠르게 두 번 누르거나 네트워크 재전송으로 같은 Command가 두 번 들어왔을 때 어떻게 막을 것인지 — Idempotency Key 같은 결정이 필요한 지점이에요.

 

2. "미결제 상태 DB 저장? in-memory?" (Event 옆)
이건 실제로 고민하셨던 주제와 직접 닿아있는 의문이죠. "결제 요청됨" 상태를 Room에 영속화할지, Flow로만 흘려보낼지의 결정 포인트입니다.

 

3. "PG사 장애 시 재시도 정책?" (Policy 위)
Policy 자체가 실패할 수 있는 외부 호출을 트리거하기 때문에, 그 실패를 어떻게 다룰지가 핫스팟이 됩니다.

 

4. "타임아웃 발생 시 처리 방법?" (Aggregate-Event 사이)
Aggregate가 PG사 응답을 기다리는 동안 시간이 초과되면 결제 상태를 어떻게 둘지 — "결제 실패됨" Event를 만들지, "결제 보류됨"으로 둘지의 결정.

 

*Hotspot의 진짜 가치는 워크샵 끝에 빨간 포스트잇이 어디 몰려있는지 보는 것. 빨간 게 많이 붙은 영역은 도메인 전문가도 명확한 답을 못 가진 곳, 즉 시스템에서 가장 위험하고 가장 깊이 설계해야 할 부분 위 그림에서도 Policy~Cycle 2 구간에 핫스팟이 몰려있다. 외부 시스템(PG사)과의 통신이 가장 불확실성이 높다는 뜻이고, 이게 실제 결제 도메인의 본질적인 어려움을 반영합니다.

READ MODEL이 추가된 이벤트 스토밍

읽기 모델(Read Model)은 사용자가 어떤 행동(커맨드)을 하기 전에 의사결정을 내릴 수 있도록 돕는 정보의 덩어리를 의미합니다.

단순한 '화면 디자인'과의 차이점

이벤트 스토밍에서 이를 단순한 UI 스케치라고 부르지 않고 굳이 '읽기 모델'이라는 용어를 쓰는 이유는 기술적인 데이터 구조(CQRS 패턴)와 연결되기 때문입니다.

• 명령(Command)을 위한 데이터: 데이터를 저장하고 수정할 때 필요한 데이터 구조 (예: 정규화된 DB 테이블)
• 조회(Query)를 위한 데이터: 사용자가 화면에서 오직 '조회'만 하기 위해 여러 테이블을 조합하거나 미리 가공해 둔 데이터 구조 (예: 역정규화된 조회용 데이터)

즉, 이벤트 스토밍에서의 읽기 모델은 "사용자가 커맨드를 유발하기 위해 시스템으로부터 요구하는 최적화된 데이터 뷰(View)"라고 이해하시면 설계 관점에서 가장 완벽합니다.

 

 

Android 개발 관점에서 Read Model은 UI State 와 거의 1:1 매핑됩니다.

• 결제 화면 → PaymentScreenState (StateFlow로 관찰)
• 결제 결과 화면 → PaymentResultState

그리고 여기서 흥미로운 점은, Event를 어디서 가져와서 Read Model을 만들 것인가가 바로 in-memory vs DB-first 결정과 직결된다. Read Model을 Room에서 쿼리해서 만들면 DB-first SSOT 패턴이 되고, 메모리에 보관된 Event Stream에서 직접 파생시키면 in-memory CQRS가 되는 거죠. 이벤트 스토밍에서 Read Model 포스트잇 옆에 빨간 Hotspot을 붙여 "이 Read Model은 어디서 파생되어야 하는가?"를 표시해두면, 워크샵에서 바로 그 결정을 논의할 수 있다.