Refactor: Consolidate directory structure into 5 main categories and update metadata

10_Wiki/Topics_Dev/Event_Storming.md

@@ -1,48 +1,47 @@
 ---
-id: P-REINFORCE-WIKI-DEV-EVENT-STORMING
-title: "이벤트 스토밍과 비즈니스 프로세스 모델링 (Event Storming)"
-category: "10_Wiki/💻 Topics_Dev"
+id: P-REINFORCE-WIKI-ARCH-EVENT-STORMING
+title: "이벤트 스토밍 기반의 도메인 탐색 (Event Storming)"
+category: Dev
 status: verified
 canonical_id: ""
-aliases: ["이벤트 스토밍", "Event Storming", "도메인 모델링 워크샵", "DDD 워크샵"]
+aliases: ["이벤트 스토밍", "Event Storming", "도메인 탐색 워크샵", "비즈니스 모델링"]
 duplicate_of: ""
 source_trust_level: A
 confidence_score: 1.0
-tags: ["DDD", "Modeling", "Workshop", "Business_Analysis", "Collaboration"]
+tags: ["DDD", "Collaboration", "Strategic_Design", "Event_Storming", "Modeling"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
 ---
 
-# [[이벤트 스토밍과 비즈니스 프로세스 모델링 (Event Storming)]]
+# [[이벤트 스토밍 기반의 도메인 탐색 (Event Storming)]]
 
 ## 1. 개요
-이벤트 스토밍(Event Storming)은 복잡한 비즈니스 도메인을 신속하게 탐색하고 모델링하기 위한 협업 워크샵 기법이다. 개발자와 아키텍트뿐만 아니라 도메인 전문가(현업 담당자)가 모두 참여하여, 시스템에서 발생하는 주요 사건인 '도메인 이벤트'를 중심으로 비즈니스 흐름을 시각화하고 공통의 이해를 구축하는 데 중점을 둔다.
+이벤트 스토밍(Event Storming)은 비즈니스 도메인을 깊이 탐색하고 복잡한 시스템의 구조를 식별하기 위한 협업 워크샵 기법이다. 개발자, 아키텍트, 도메인 전문가가 함께 참여하여 서비스의 흐름을 시각화하고, 도메인 이벤트(Domain Events), 명령(Commands), 애그리거트(Aggregates) 등 핵심 설계 요소를 신속하게 도출하는 데 최적화되어 있다.
 
-## 2. 핵심 구성 요소 및 진행 절차
-워크샵은 주로 거대한 벽면에 포스트잇을 붙이는 방식으로 진행되며, 다음과 같은 색상별 요소를 식별한다.
-- **도메인 이벤트 (Orange)**: 비즈니스상 의미 있는 과거에 발생한 사건 (예: '주문이 완료됨').
-- **명령 (Blue)**: 이벤트를 트리거하는 사용자 액션이나 시스템 요청 (예: '상품 주문하기').
-- **애그리거트 (Yellow)**: 명령을 처리하고 데이터의 일관성을 유지하는 비즈니스 규칙의 집합 (예: '주문 정보').
-- **외부 시스템 (Pink)**: 우리 시스템 밖의 서드파티 서비스나 인프라.
-- **핫스팟 (Purple/Red)**: 이해관계자 간 의견이 충돌하거나 논의가 더 필요한 불확실한 지점.
+## 2. 워크샵 구성 요소
+- **도메인 이벤트 (Orange Card)**: 비즈니스에서 발생한 과거 시점의 중요한 사건. 시스템의 상태 변화를 나타냄.
+- **명령 (Blue Card)**: 사용자의 의도나 시스템에 의해 발생하는 동작. 이벤트를 트리거함.
+- **애그리거트 (Yellow Card)**: 명령을 받아 이벤트를 생성하는 데이터와 로직의 군집(트랜잭션의 단위).
+- **액터/사용자 (Small Yellow)**: 명령을 수행하는 주체.
+- **정책 (Lilac Card)**: 이벤트가 발생했을 때 자동으로 실행되는 반응 로직.
 
-## 3. 엔지니어링 가치
-- **도메인 지식의 동기화**: 개발자와 현업 간의 용어 불일치(Language Gap)를 해소하고, 코드베이스에 비즈니스 의도가 정확히 반영되도록 유도.
-- **마이크로서비스 경계 도출**: 이벤트의 흐름과 애그리거트 간의 관계를 통해 자연스럽게 바운디드 컨텍스트(Bounded Context)를 식별하고 서비스 분할 전략 수립.
-- **요구사항 분석 가속화**: 수백 페이지의 문서 대신 시각적인 맵을 통해 시스템의 전체 프로세스를 단 몇 시간 만에 파악하고 잠재적인 설계 결함 조기 발견.
+## 3. 실전 적용 가치
+- **비즈니스-기술 싱크로**: 도메인 전문가의 지식을 개발자가 즉각적으로 이해하고 모델링에 반영 가능.
+- **병목 지점 식별**: 전체 프로세스를 시각화하는 과정에서 비즈니스상의 비효율이나 병목 지점을 자연스럽게 발견.
+- **아키텍처 설계의 뼈대**: 도출된 이벤트와 애그리거트는 바운디드 컨텍스트를 정의하고 마이크로서비스 경계를 나누는 결정적 근거가 됨.
 
 ## 4. 트레이드오프 및 주의사항
-- **도메인 전문가의 참여 필수**: 기술진만 참여할 경우 비즈니스 실재와 동떨어진 '기술적 상상'에 그칠 위험이 크다. 반드시 현업 전문가의 활발한 참여가 보장되어야 함.
-- **구현 복잡성과의 타협**: 이벤트 스토밍으로 도출된 모든 세밀한 로직을 전부 이벤트 기반으로 구현할 필요는 없다. 비즈니스 중요도에 따라 단순한 CRUD로 구현할 영역과 정교한 DDD/EDA를 적용할 영역 구분 필요.
-- **정적 산출물로의 변환**: 워크샵의 결과물은 휘발되기 쉬우므로, 즉시 다이어그램(Mermaid, Lucidchart 등)이나 코드로 기록하여 지식의 영속성 확보.
+- **장점**: 짧은 시간 내에 복잡한 도메인에 대한 공통 멘탈 모델 형성.
+- **단점**: 도메인 전문가의 적극적인 참여 없이는 반쪽짜리 결과가 나올 수 있으며, 대규모 인원이 참여할 경우 퍼실리테이션 역량이 중요함.
+- **주의**: 시각화된 결과물에만 집중하지 말고, 그 과정에서 오가는 '대화'와 '보편적 언어'의 확립을 최우선으로 할 것.
 
 ## 5. 지식 연결 (Related)
-- [[Domain_Driven_Design]]: 이벤트 스토밍이 지향하는 상위 설계 패러다임.
-- [[Event_Driven_Architecture]]: 도출된 도메인 이벤트를 기술적으로 구현하는 아키텍처 스타일.
-- [[Aggregates]]: 데이터와 비즈니스 로직의 트랜잭션 경계.
+- [[Domain_Driven_Design]]: 이벤트 스토밍을 통해 구현하고자 하는 설계 철학.
+- [[DDD_Aggregates]]: 이벤트 스토밍에서 도출된 핵심 데이터 관리 단위.
+- [[Event_Driven_Architecture]]: 도메인 이벤트를 물리적으로 구현하는 아키텍처 스타일.
 
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 비즈니스 복잡성을 기술 구조로 정확히 전이시키고, 팀 간의 협업적 설계를 가속화하기 위한 도메인 분석 표준 방법론 정립.
+- **검토 이유**: 도메인 모델링과 시스템 설계를 위한 실천적인 협업 프레임워크 표준 정립.