Event Storming 是 Alberto Brandolini 在 2013 年提出的協作工作坊格式，目的是把一個複雜業務領域的知識，從散落在不同人頭腦裡的狀態，帶到一張牆壁或白板上的共同視覺模型。它刻意不從 UML、資料庫 schema 或 API 開始——它從領域事件（Domain Events）開始，因為事件是領域裡「確實發生了什麼」最直接的語言。
可佐證：Brandolini 的書《Introducing EventStorming》由 Leanpub 出版，官網 eventstorming.com 提供公開資源。IBM Cloud Architecture 有獨立整理的工作坊方法論文件。
三個層次
Event Storming 不是單一格式，而是同一套符號語言在三個深度上的應用：
Big Picture（全局探索）
目的：探索整個業務領域，找出領域事件、痛點、組織邊界。
規模：可容納 25–30 人，涵蓋 PM、工程師、領域專家、業務人員。
輸出：一條（或多條）完整的時間軸，標出所有重要的 Domain Events，以及紅色的 Hotspot（尚未解決的問題點）。
這個階段刻意不要求精確——目的是把所有人對領域的理解攤在同一張大圖上，讓分歧、矛盾、假設差異浮現。
Process Modeling（流程建模）
目的：針對一條特定業務流程，從頭到尾走一遍，加入明確的語法元素。
規模：較小群體（5–15 人），聚焦在一個子領域。
輸出：帶有 Commands、Actors、External Systems 的詳細流程圖，找出策略問題。
Design Level（設計層）
目的：進入軟體設計，把流程建模的輸出轉成可實作的軟體結構。
規模：工程師主導（3–8 人），可能包含架構師。
輸出：Aggregates、Bounded Contexts、API 邊界、技術決策點。
這三層不一定都做——Big Picture 適合探索階段，Design Level 適合 sprint 前的設計。可以根據問題的清晰度選擇從哪一層開始。
便利貼語法
Event Storming 用顏色區分不同語義的卡片（以下為 Brandolini 定義的標準，各團隊有時會調整顏色但保留意義）：
| 顏色 | 元素 | 說明 | 範例 |
|---|---|---|---|
| 橘色 | Domain Event | 領域裡已發生的事，用過去式動詞命名 | OrderPlaced、PaymentReceived |
| 藍色 | Command | 意圖改變狀態的動作，用現在式命令動詞 | PlaceOrder、CancelOrder |
| 黃色（小） | Actor | 發出 Command 的人或系統角色 | Customer、Admin |
| 淡黃色（大） | Aggregate | 處理 Command、保證不變量、發出 Event 的一致性邊界 | Order、Account |
| 粉色 | External System | 邊界外的系統，可發出事件或接收指令 | Payment Gateway、Email Service |
| 紫色 | Hotspot | 尚未解決的問題、爭議、待釐清的假設 | 「退款需要多久？」、「庫存扣減時機？」 |
| 紫丁香色 | Policy / Business Rule | 當某事件發生時，自動觸發的規則（When … Then …） | When PaymentReceived Then ConfirmOrder |
| 綠色 | Read Model / View | 用戶或系統決策時需要看到的資訊快照 | OrderSummary、InventoryStatus |
命名慣例：Domain Events 用過去式被動語態命名（OrderPlaced 而非 PlaceOrder），強調「這件事已發生，不可撤銷」的語義。
從便利貼到 Bounded Contexts
Event Storming 的核心輸出不只是便利貼，而是透過便利貼聚集後識別出 Bounded Contexts：
- 把相關的 Domain Events、Commands、Aggregates 圍在一起
- 找出不同群組之間的通訊介面（Command 或 Event 跨群組傳遞）
- 用實線框標出每個 Bounded Context，命名它（用領域語言，不是技術語言）
- 畫 Context Map：標出各 Context 之間的關係類型（Upstream/Downstream、Partnership、Anti-Corruption Layer 等）
一個典型電商系統跑完 Big Picture 後，可能識別出：Order Management、Inventory、Payment、Shipping、Customer Profile 等幾個 Bounded Context。
工作坊 artifact 清單
Event Storming 結束後，這條流程的下游步驟需要以下 artifact：
✓ Domain Events 清單（命名 + 所屬 Bounded Context）
✓ Commands 清單（每個 Command 對應的 Actor 和 Aggregate）
✓ Aggregates 清單（名稱 + 核心不變量的口頭描述）
✓ Bounded Contexts 邊界圖（含 Context Map）
✓ Hotspot 清單（未解決問題，供 Problem Frames W Register 接收）
✓ Key Policies（When … Then … 規則，影響後端事件處理邏輯）
Hotspot 清單尤其重要——它直接對應 kiro-frame 的 W Register 中標記為 to-confirm 的 Domain Assumptions。
已知批評與適用時機
優點（可佐證的業界共識）：
- 讓非技術人員（PM、業務）和技術人員在同一個視覺模型上對話，減少「翻譯損耗」
- 通過命名事件而非資料庫欄位，迫使討論停留在業務語言層次
- Hotspot 機制把爭議顯性化，不讓它在工作坊裡被悄悄掩蓋
已知限制（方法論主張 + 已記錄批評）：
- Big Picture 需要真人協作和熟練的 facilitator；遠端工具（Miro 等）可用，但 Brandolini 個人傾向實體工作坊
- 識別 Bounded Contexts 的邊界是藝術而非科學——同一組便利貼可能被不同人劃出不同邊界
- 「何時一個 Aggregate 夠大或夠小」在工作坊中很難決定，往往需要 Design Level 才能釐清
- 不適合問題已非常清楚的小功能（一個 CRUD 頁面不需要 Big Picture Event Storming）
延伸
- 把 Hotspot 清單轉成 W Register → kiro-frame：Problem Frames 形式化工具
- 把 Aggregates 落地成 Event Store → Event Sourcing + CQRS：後端落地
- 實戰範例中的 Event Storming 步驟 → 完整流程實戰：電商訂單系統走一遍
- 回到全景 → Event Storming + Event Sourcing + Pattern Language 專欄首頁