2024年9月24日
Event Storming 怎麼跑？從準備、Big Picture 的七個步驟，到 Process Modeling 的便利貼語法
DDD 概論 簡單介紹過 Event Storming，Domain Storytelling 那篇也比較過兩者的差別。這段時間實際主持了幾場，發現光知道「橘色是事件、藍色是命令」遠遠不夠，一場 Event Storming 成不成功，八成取決於準備和主持。這篇把流程完整整理一次。
三種層次
Event Storming 由 Alberto Brandolini 提出，依目的不同分成三種層次：
| 層次 | 目的 | 參與者 | 時間 |
|---|---|---|---|
| Big Picture | 看清楚整個業務的全貌，找出問題與邊界 | 各部門的領域專家、PO、開發人員 | 半天到一天 |
| Process Modeling | 拆解一個流程，弄清楚每一步的規則 | 該流程的領域專家、PO、開發人員 | 2～4 小時 |
| Software Design | 設計聚合、命令與事件，直接對應到程式 | 開發人員為主，領域專家在旁回答問題 | 2～4 小時 |
三者是由寬到窄的關係：Big Picture 找出最值得處理的流程，Process Modeling 把那個流程拆清楚，Software Design 再把它變成程式的設計。這篇主要介紹前兩種。
準備
找對人
最重要的一件事。Event Storming 的價值來自不同部門的知識碰在一起，所以要找：
- 真正做事的領域專家：資深經紀人、店長、負責簽約的同事、財務。只找主管來，常常只會聽到「規定上應該怎麼做」
- 開發人員：他們會問出業務沒想過的問題，例如「斡旋過期的那一刻，系統要做什麼？」
- PO：最後要決定優先順序的人
- 主持人：最好不是領域專家，也不是要做決定的人，才能保持中立
Big Picture 大約 8～15 人最適合。少於 5 人看不到全貌，超過 20 人很難讓每個人都參與。
準備空間與材料
- 一面很長的牆：至少 6～8 公尺，貼上大張的海報紙或白報紙卷。牆不夠長，時間軸會被迫折行，就看不出全貌
- 把椅子移開：大家站著才會走動、會靠過去看別人貼了什麼。坐著開會很快就變成一兩個人在講
- 大量的便利貼：橘色要準備最多，一場 Big Picture 用掉幾百張很正常
- 粗的黑色簽字筆：每人一支。不要用原子筆，字太小，遠一點就看不到；字寫不下也會逼大家寫得簡潔
- 圖例：把每種顏色代表什麼，先貼在牆的一角
遠端進行可以用 Miro 這類線上白板，先把時間軸和圖例準備好。但線上很難達到實體的效果：大家容易各自安靜地貼，討論變少，主持人要更主動點名。
便利貼的顏色與語法
| 顏色 | 元素 | 說明 |
|---|---|---|
| 橘色 | 領域事件（Domain Event） | 業務上發生、而且有人在意的事，用過去式：「斡旋已提出」 |
| 藍色 | 命令（Command） | 使用者的意圖或決定：「提出斡旋」 |
| 小張黃色 | 角色（Actor） | 發出命令的人：買方、經紀人 |
| 淡紫色 | 政策（Policy） | 「每當…就…」的反應規則，可以是自動的，也可以是某人的固定做法 |
| 綠色 | 讀取模型（Read Model） | 角色做決定前需要看到的資訊 |
| 大張黃色 | 聚合／系統 | 接收命令、檢查規則、產生事件的地方 |
| 粉紅色 | 外部系統 | 不在我們控制範圍內的系統：簡訊服務、銀行 |
| 桃紅色（斜貼） | 熱點（Hot Spot） | 疑問、衝突、痛點，任何人隨時都可以貼 |
各團隊的顏色不完全一樣，重要的是同一場裡保持一致，並把圖例貼在牆上。
為什麼事件要用過去式
「斡旋已提出」和「提出斡旋」看起來只差兩個字，但意義完全不同：
- 過去式代表已經發生的事實，不能被拒絕、不能被撤銷，只能用另一個事件來抵銷（例如「斡旋已撤回」）
- 它逼大家講業務結果，而不是系統動作。「資料已寫入資料庫」、「API 已呼叫」不是領域事件，業務人員看不懂，也不在意
- 事件是最容易達成共識的：大家對「該怎麼做」可能意見不同，但對「發生了什麼」通常很快有共識
Big Picture：七個步驟
0. 開場（10 分鐘）
說明今天的目的、範圍（例如「從屋主委託到交屋」）、規則，以及圖例。範圍的起點和終點要講清楚，否則會有人從公司成立開始講。
1. 混亂探索（20～30 分鐘）
每個人各自把自己知道的領域事件寫在橘色便利貼上，大致依時間順序貼到牆上。
- 不討論、不糾正：這個階段要的是數量，重複的、寫錯的之後再處理
- 自己負責的部分就貼：財務只知道服務費怎麼收，那就貼那一段
一開始大家會很拘謹，主持人可以自己先貼幾張示範，再點名：「店長，斡旋那一段您最熟，可以先貼嗎？」
2. 整理時間軸（30～60 分鐘）
大家一起把便利貼排成一條合理的時間軸：
- 合併重複的：兩張寫法不同但意思一樣的，選一個大家都接受的說法。如果合不起來，代表其實是兩件事，或是語言有分歧，貼一張熱點
- 補上缺漏：時間軸上出現跳躍，問「這兩件事中間還發生了什麼？」
- 平行的流程分成泳道：例如「帶看」和「斡旋金保管」可以同時進行，上下分開排
這個階段最容易吵起來，例如業務認為「斡旋已接受」就是成交，財務認為「買賣契約已簽訂」才算。不需要當場吵出結果，貼一張熱點，繼續往下走。
3. 找出關鍵事件與邊界（20 分鐘）
找出幾個改變業務階段的事件，例如「物件已上架」、「斡旋已接受」、「買賣契約已簽訂」，在它們後面用膠帶或垂直線把時間軸分段，並在每段上方寫一個名稱。
這些分段就是子域或限界上下文的候選。之後可以再用 子域劃分 那篇的方法，判斷每一段是核心、支撐還是通用。
4. 補上人與系統（20 分鐘）
在事件旁邊貼上小張黃色的角色，以及粉紅色的外部系統：誰讓這件事發生的？依賴了哪個系統？
這一步常常會發現交接的問題，例如「斡旋金已收取」之後，到底是經紀人還是店長保管？兩個人的說法不一樣。
5. 標出熱點（全程）
熱點不是一個獨立的階段，而是整場都可以貼。任何疑問、衝突、「這裡常常出問題」都貼上去。熱點越多，代表這場越有價值：這些問題本來就存在，只是之前沒被看到。
6. 走一遍、倒著走（30 分鐘）
- 走一遍（Explicit Walk-through）：請一位參與者從頭講一次整條時間軸，其他人邊聽邊補充。講不下去的地方，通常就是缺了事件
- 倒著走（Reverse Narrative）：從最後一個事件往回問「要發生這件事，前面必須先發生什麼？」。往前走容易只講順利的情況，倒著走比較容易發現前置條件，例如「服務費已收取」之前，必須先有「服務費已確認」
7. 問題與機會、投票（20 分鐘）
最後請每個人寫下他認為最大的問題或機會，再用箭頭投票：每人兩票，畫在他認為最該優先處理的熱點或事件上。
票數最多的地方，就是接下來要用 Process Modeling 深入的流程。
收尾
- 拍照：整面牆分段拍清楚，最好有人負責整理成數位版
- 整理熱點清單：每個熱點寫下要問誰、誰負責追
- 說明下一步：讓參與者知道這場的結果會怎麼被使用，下次才找得到人
Process Modeling：把一個流程拆清楚
Big Picture 投票選出「斡旋」這段後，找相關的人再跑一場 Process Modeling。這時要用上完整的語法，規則很簡單：
- 每個事件前面都有原因：可能是某個角色發出的命令，也可能是一條政策
- 每個命令前面都有角色或政策，角色在發出命令前，通常需要看某個讀取模型
- 每個事件後面接政策、讀取模型，或是流程結束
照著這個語法串下去，就會被迫回答很多 Big Picture 時跳過的問題：
- 買方提出斡旋時，需要看到什麼資訊？（讀取模型：物件資訊、目前是否已經有人斡旋）
- 「斡旋已提出」之後，誰會知道？怎麼知道？（政策：通知屋主的經紀人）
- 斡旋期限到了，誰來處理？（政策：每當斡旋到期，就把斡旋標記為過期、退還斡旋金）
- 屋主同時收到兩組斡旋時，規則是什麼？（熱點：先到先處理，還是屋主自己選？）
Process Modeling 的產出很接近需求規格：命令就是功能，事件就是功能完成的結果，政策就是要自動化或要人工處理的規則，熱點就是還沒定案的問題。
Software Design：再往下一層
如果團隊要開始寫程式，可以再跑一場 Software Design：把相關的命令和事件圍繞著聚合重新整理，問每個聚合要守住哪些規則。例如「斡旋已提出」、「斡旋已接受」、「斡旋已過期」都圍繞著「斡旋」這個聚合，「物件已上架」、「物件已改價」則屬於「物件」聚合。這部分可以參考 DDD 概論 裡的聚合設計原則。
主持人的技巧
- 控制時間，不控制內容：每個階段都有時間盒，到了就進下一步。內容由參與者決定
- 事件要用業務語言：看到「訂單資料已更新」，問「業務上發生了什麼事？」
- 衝突先貼熱點：不要讓兩個人在牆前吵十分鐘，其他人站著等
- 注意沒說話的人：資淺的人常常最清楚實際狀況，但不敢在主管面前說。主持人可以直接問他們負責的那段
- 不要讓開發人員主導：開發人員容易把討論帶到「資料表怎麼設計」，Big Picture 階段先專注在業務
- 事前和關鍵人物溝通：如果主管會參加，事前說明這不是報告會，是一起探索，請他多聽少講
常見的失敗
| 狀況 | 原因 | 改善 |
|---|---|---|
| 牆上都是「點擊按鈕」、「呼叫 API」 | 參與者以系統操作的角度思考 | 開場用業務事件示範，過程中隨時提醒 |
| 只有兩三個人在貼 | 坐著開會、主管在場、沒有點名 | 移開椅子，主持人主動邀請每個部門 |
| 吵了一小時沒有結論 | 想在當下解決所有分歧 | 衝突貼熱點，會後再找對的人解決 |
| 貼完就沒有下文 | 沒有整理產出、沒有指定負責人 | 收尾時整理熱點清單與下一步 |
| 範圍太大，一天貼不完 | 開場沒有定義起點和終點 | 先跑 Big Picture，細節留給 Process Modeling |
一句話總結
Event Storming 的關鍵在準備與主持：找齊真正做事的人、準備夠長的牆和站著的空間，Big Picture 先讓每個人各自貼出過去式的領域事件，再一起整理時間軸、找出關鍵事件與邊界、補上人與系統、隨時標出熱點，最後走一遍並投票選出最該處理的問題；選出的流程再用 Process Modeling 的「角色、命令、聚合、事件、政策、讀取模型」語法拆清楚。