Files
2nd/10_Wiki/Topics_Dev/Event_Storming.md
T

3.8 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit
P-REINFORCE-WIKI-DEV-EVENT-STORMING 이벤트 스토밍과 비즈니스 프로세스 모델링 (Event Storming) 10_Wiki/💻 Topics_Dev verified
이벤트 스토밍
Event Storming
도메인 모델링 워크샵
DDD 워크샵
A 1.0
DDD
Modeling
Workshop
Business_Analysis
Collaboration
Datacollector_Export_2026-05-02
2026-05-02

이벤트 스토밍과 비즈니스 프로세스 모델링 (Event Storming)

1. 개요

이벤트 스토밍(Event Storming)은 복잡한 비즈니스 도메인을 신속하게 탐색하고 모델링하기 위한 협업 워크샵 기법이다. 개발자와 아키텍트뿐만 아니라 도메인 전문가(현업 담당자)가 모두 참여하여, 시스템에서 발생하는 주요 사건인 '도메인 이벤트'를 중심으로 비즈니스 흐름을 시각화하고 공통의 이해를 구축하는 데 중점을 둔다.

2. 핵심 구성 요소 및 진행 절차

워크샵은 주로 거대한 벽면에 포스트잇을 붙이는 방식으로 진행되며, 다음과 같은 색상별 요소를 식별한다.

  • 도메인 이벤트 (Orange): 비즈니스상 의미 있는 과거에 발생한 사건 (예: '주문이 완료됨').
  • 명령 (Blue): 이벤트를 트리거하는 사용자 액션이나 시스템 요청 (예: '상품 주문하기').
  • 애그리거트 (Yellow): 명령을 처리하고 데이터의 일관성을 유지하는 비즈니스 규칙의 집합 (예: '주문 정보').
  • 외부 시스템 (Pink): 우리 시스템 밖의 서드파티 서비스나 인프라.
  • 핫스팟 (Purple/Red): 이해관계자 간 의견이 충돌하거나 논의가 더 필요한 불확실한 지점.

3. 엔지니어링 가치

  • 도메인 지식의 동기화: 개발자와 현업 간의 용어 불일치(Language Gap)를 해소하고, 코드베이스에 비즈니스 의도가 정확히 반영되도록 유도.
  • 마이크로서비스 경계 도출: 이벤트의 흐름과 애그리거트 간의 관계를 통해 자연스럽게 바운디드 컨텍스트(Bounded Context)를 식별하고 서비스 분할 전략 수립.
  • 요구사항 분석 가속화: 수백 페이지의 문서 대신 시각적인 맵을 통해 시스템의 전체 프로세스를 단 몇 시간 만에 파악하고 잠재적인 설계 결함 조기 발견.

4. 트레이드오프 및 주의사항

  • 도메인 전문가의 참여 필수: 기술진만 참여할 경우 비즈니스 실재와 동떨어진 '기술적 상상'에 그칠 위험이 크다. 반드시 현업 전문가의 활발한 참여가 보장되어야 함.
  • 구현 복잡성과의 타협: 이벤트 스토밍으로 도출된 모든 세밀한 로직을 전부 이벤트 기반으로 구현할 필요는 없다. 비즈니스 중요도에 따라 단순한 CRUD로 구현할 영역과 정교한 DDD/EDA를 적용할 영역 구분 필요.
  • 정적 산출물로의 변환: 워크샵의 결과물은 휘발되기 쉬우므로, 즉시 다이어그램(Mermaid, Lucidchart 등)이나 코드로 기록하여 지식의 영속성 확보.

🧪 검증 상태 (Validation)

  • 정보 상태: 검증 완료 (Verified)
  • 출처 신뢰도: A
  • 검토 이유: 비즈니스 복잡성을 기술 구조로 정확히 전이시키고, 팀 간의 협업적 설계를 가속화하기 위한 도메인 분석 표준 방법론 정립.