Event Storming 演練 - 停車場系統 - 下
Published
•2 min read邊界情境
實際做法：
當大家走到「車輛靠近入口 → 辨識 → 進場」的事件時，突然有人問：
「那如果有人卡在入口不走呢？」
此時 facilitator（主持人）會立刻拿一張粉紅貼紙寫：
複製編輯🚧 車輛卡在入口太久然後貼在「車輛靠近入口」的旁邊，不急著解決，先繼續主流程。
快速記錄格式（現場慣用）
| 元素 | 怎麼寫 |
| 事件 | 粉紅貼紙，寫「異常行為：XXX」 |
| 策略建議 | 藍貼紙，可直接寫「應提示駕駛讓道」 |
| 命令建議 | 黃貼紙，可寫「發送通知、記錄異常」 |
👉 不強求完整性，能留下「問題意識」即可。
會議進行節奏（常見做法）
先走主流程，重要事件先黏出來
出現問題→邊緣→立即貼異常，不討論細節
流程完整後，再回頭處理粉紅貼紙
邊界情境可延伸成 Hot Spot 討論、風險評估、技術突破設計
邊界情境（Edge Cases）→ 轉化為正式「事件（Domain Events）」的情況
💡 核心原則：
- 只要一個情境有「業務意義」、會「改變狀態」、或「需要反應」
👉 它就應該升級為正式的 事件。
🚦 停車場案例：從邊界到事件的示範
| 邊界情境（粉紅貼紙） | 能否轉為事件？ | 為什麼 |
| 車輛長時間佔入口不走 | ✅ 可以轉為事件：「車輛佔入口超時」 | 系統需要反應（提示、通知、控制） |
| 車牌辨識失敗 | ✅ 可以轉為事件：「車牌辨識失敗」 | 需觸發手動模式或人工協助 |
| 車輛進場後長期未出場 | ✅ 可以轉為事件：「車輛停留時間過長」 | 可觸發異常計費或管理提醒 |
| 繳費後未出場 | ✅ 可以轉為事件：「出場有效期過期」 | 決定是否重新計費或通知 |
| 發票開立失敗 | ✅ 可以轉為事件：「發票開立失敗」 | 觸發補救措施 |
| 感應器故障 | ✅ 可以轉為事件：「設備異常發生」 | 系統行為需切換或通報 |
📌 為什麼要轉為事件？
| 理由 | 說明 |
| 🏷 有狀態變化 | 例如：一輛車從「正常停車」→「超時停車」 |
| 🔄 需要後續行為 | 例如：需自動扣費、發送通知、變更模式 |
| 📊 需要日後追蹤 | 例如：異常統計、營運報表、責任歸屬 |
| ⏱ 時間驅動 | 例如：經過 X 分鐘未付款／未出場，都是時間驅動事件 |
🚀 如何處理這類「從粉紅到橘色」的轉變？
事件名稱（橘色貼紙）：描述「發生了什麼」（過去式）
策略規則（藍色貼紙）：描述「應該做什麼」
行動命令（黃色貼紙）：描述「執行什麼行為」
📍 停車場 E1 實例演練：
| 元素 | 實際內容 |
| Event | 車輛佔入口超時 |
| Policy | 系統應提示駕駛並通知管理者 |
| Command | 顯示提示／發送通知／記錄異常 |
這樣一來它就變成完整的「業務驅動流程」，而不是一個單純的「提醒」。
✅ 決策準則：何時邊界變事件？
| 問題 | 結論 |
| 有沒有「新狀態」產生？ | 有 → 應該變事件 |
| 有沒有「需要反應或處理」？ | 有 → 應該變事件 |
| 是否影響到其他業務行為？ | 有 → 應該變事件 |
| 是否僅是提醒、告警？ | 是 → 保持粉紅貼紙即可 |
