軟體專案最昂貴的災難，往往不是技術選型失誤，而是**「工程團隊用極其高超的技術，完美實現了一個業務專家根本不需要的錯誤系統」**。
在傳統的軟體開發流程中，「系統分析（System Analysis）」通常以一種高度低效的接力形式展開：
產品經理（PM）或業務分析師（BA）花費數週訪談業務專家，寫下一份上百頁滿是表格、使用案例（Use Cases）與流程圖的規格說明書（PRD）；隨後，架構師接過這份文件，按照自己的技術認知將其轉譯為資料庫實體關聯圖（ER Diagram）與 RESTful API Schema；最後，工程師開始建立資料表，並用千篇一律的 CRUD 邏輯將代碼填滿。
直到系統上線當天，業務人員驚慌失措地喊道：「等等！退貨的時候怎麼可以直接把庫存扣回去？退回來的商品必須先經過『品檢入庫隔離區』驗收，確認非人為損壞後才能重新上架！這在我們產業是常識啊！」
工程師與架構師則面面相覷：「當初 PRD 上只寫著『使用者可申請退貨』，資料庫設計就是把 status 改成 REFUNDED 並且把 stock_quantity + 1 啊！」
這種跨職能的語義斷層與認知盲點，正是 Alberto Brandolini 創造 EventStorming（事件風暴） 要徹底摧毀的目標。
為什麼傳統訪談式需求分析必然漏掉關鍵約束？
傳統的需求分析訪談本質上是一種**「失真的二手轉譯（Second-hand Translation）」**。
人類在透過自然語言描述日常工作時，存在嚴重的「專家詛咒（Curse of Knowledge）」——那些對業務專家而言如同呼吸般自然的隱性業務不變量（Invariants）、異常處置流程與跨部門潛規則，專家在被動受訪時根本不會主動提及；而系統分析師在缺乏全域業務時序的情況下，只能用自己熟悉的「使用者介面與資料表 CRUD」框架去套用對方的零散回答。
更致命的是，軟體工程師與業務專家在會議室裡天然使用兩套完全無法互通的思維語言：
- 業務人員關注業務事實與因果結果：合約簽署、保險核保通過、款項逾期催繳。
- 工程人員關注資料結構與儲存狀態：資料表欄位、外鍵約束、同步或非同步 RPC。
要打破這堵溝通高牆，我們必須強迫所有人脫離資料庫與實體，退回到一個連外行人都能直觀理解的最底層原子——「在業務世界中，過去到底發生了哪些不可逆的真實事實？」
這就是 EventStorming 的第一核心基石：領域事件（Domain Events）。
Big Picture EventStorming：全景事件風暴四步法
與專注於單一聚合根（Aggregate）設計的 Design-Level EventStorming 不同，Big Picture EventStorming（全景事件風暴） 的唯一目標，是拉高視角，在整個業務生態的宏觀維度上，找出系統的「自然接縫」與「語義邊界」。
進行全景風暴時，必須清空會議室的所有桌椅，準備一面至少十公尺長的空白牆面（或連續捲筒白紙），並嚴格按照以下四個階段推進：
第一步：混沌發散——領域事件（Domain Events）
將橘色便籤發給在場所有人（業務、產品、架構師、測試工程師、資深開發者），設定 15 到 20 分鐘的倒數計時。所有人同時動筆，將自己所知道在業務流程中發生的所有事實貼上牆面。
- 書寫硬規則： 必須且只能使用**「過去式動詞」**（Past-Tense Verbs）。例如
OrderPlaced（訂單已建立）、PaymentReceived（款項已入帳）、ParcelDispatched（包裹已寄出）。 - 嚴格禁令： 絕對不允許出現 CRUD 動詞！ 諸如
CreateOrder、UpdateInventory、DeleteUser這類技術名詞，必須當場撕掉重寫。因為資料庫的變更不是業務事實，「使用者下單」才是業務事實。 - 推進姿態： 不做任何過濾與排序，允許便籤重複、亂序與衝突。這個階段的唯一使命是**「徹底打破專業壁壘與沉默，將所有人的隱性知識全數具象化」**。
第二步：時間軸結構化與因果溯源（Timeline & Triggers）
發散結束後，由系統分析師引導全場，將牆上數百張橘色便籤自左向右依據**「真實業務時序」**重新排列，去除完全重複的項目。接著，開始為每一個核心事件追溯因果鏈：
- 操作指令（Command，藍色便籤）： 追問這項事件是由誰發起的什麼意圖？例如在
OrderPlaced左側貼上PlaceOrder（提交訂單，由消費者發起）。 - 業務策略與政策（Policy，紫色便籤）： 追問這個事件是否會自動觸發下一步動作？其語法為「Whenever [事件 A 發生], Then [執行指令 B]」。例如「每當
PaymentReceived發生時，執行DeductInventory（扣減庫存）」。 - 讀取模型與決策上下文（Read Model，綠色便籤）： 決策者在執行這項指令前，眼前必須看到什麼資訊？例如用戶下單前需要看到
ProductCatalog（商品規格與即時庫存）。
第三步：衝突熱點收斂（Hotspots & Pain Points）
在梳理時間軸的過程中，各部門之間必然會爆發劇烈的爭議。例如業務主管堅稱：「只要客戶刷卡成功，訂單就必須立刻成立！」而風控負責人則憤怒反駁：「絕對不行！海外高風險交易必須先經過人工反洗錢審查，審查通過前訂單只是待決狀態！」
傳統會議往往會在此處陷入長達一小時的口水戰，導致流程停滯。
在 EventStorming 工作坊中，系統分析師必須執行**「衝突即刻凍結法則」**：
兩分鐘爭執停止規則（Two-Minute Freeze Rule）：
凡是跨部門針對業務規則、權責歸屬或名詞定義爭辯超過 2 分鐘，主持人立刻撕一張**亮紅色便籤（Hotspot）**貼在該事件正上方，簡明記錄爭端（例如「高風險訂單是否延遲確認？」），並強制將流程向右推進。
紅色便籤不是待修復的瑕疵，而是全系統中最具商業價值的「金礦」——衝突熱點最密集的地方，通常正是系統中最重要的架構不變量與核心業務邏輯所在。
第四步：識別候選限界上下文（Bounded Context Identification）
當時間軸梳理完畢、熱點全數標註後，站在十公尺長的事件牆前退後三步，架構師會驚奇地發現：系統的模組邊界早已清晰浮現，完全不需要憑空捏造。
系統分析師可以引導團隊尋找以下三大「天然斷裂接縫」：
- 時間軸停頓（Temporal Gaps）： 當事件流從「毫秒級即時互動」突然切換為「異步等待數小時或數天」時（例如
OrderPlaced到ParcelPickedUp），這必然是不同上下文的交界。 - 參與者與權責轉移（Actor Handover）： 當主導行為的 Actor 從消費者切換為倉庫理貨員，再切換為外部物流司機時，權責的轉移即代表業務邊界的跨越。
- 語義重心的根本轉變（Semantic Shift）： 在前端，「商品（Product）」關心的是標題、文案與行銷標籤；在庫存端，「商品」變成了 SKU 代碼、貨架編號、重量與體積；在財務端，「商品」退化為進銷存稅率與成本分攤。同一個詞在不同區段代表著完全不同的現實。
此時，拿起有色膠帶（Masking Tape），在白板上將具備高內聚時序與語義的區塊圈起來——這些被膠帶圍繞的獨立領域，就是最純正、最符合業務現實的候選限界上下文（Candidate Bounded Contexts）。
系統分析師的控場戒律：避開四大常見反模式
要成功主導一場 Big Picture EventStorming，系統分析師必須在現場扮演冷酷的邊界守門人，堅決擊碎以下四種反模式：
1. 「技術規格審查會」反模式
資深工程師最常見的職業病，就是試圖在第一步就討論：「這個事件要不要發到 Kafka？」、「資料庫要不要用 JSONB 存？」
- 防禦手段： 在工作坊開始前，明確宣布三大現場禁令：禁止討論資料庫、禁止討論傳輸協定、禁止討論微服務。 所有的討論必須維持在「真實業務世界中發生了什麼」。
2. 「大老闆一言堂」反模式
如果部門主管在白板前強勢主導，基層業務人員與第一線客服往往不敢貼出真實的異常處理流程，導致風暴結果淪為宣傳式的美化藍圖。
- 防禦手段： 在「第一步：混沌發散」中，所有人必須各自安靜寫便籤，禁止口頭交談。每個人都有平等的發言空間，唯有將便籤全部貼上牆後，才進入公開校對階段。
3. 「CRUD 狀態機假冒領域事件」反模式
當牆上出現大量 UserCreated、OrderUpdated、StatusChangedToTwo 時，代表團隊依然被關係型資料庫的思維所捆綁。
- 防禦手段： 追問這張便籤的背後動機：「為什麼 Status 會變成 2？是什麼具體業務動作導致的？」將其轉譯為
KYCVerificationPassed或CreditLimitExceeded。唯有豐富的業務語義，才能驅動出真實的架構。
4. 「完美主義時間軸阻塞」反模式
過度糾結於極罕見的特例邊界，導致團隊在第一小時連前半段流程都排不完。
- 防禦手段： 果斷將極端邊緣情況（Edge Cases）貼上紅色便籤移至白板下方，確保主幹業務流程（Happy Path）先行貫通，再回頭檢驗支線。
下一步：從事件全貌走入微觀業務敘事
透過 Big Picture EventStorming，我們成功在白板前瓦解了業務與工程的溝通藩籬，讓原本抽象的商業世界在時間軸上具象化，並從時序斷裂與權責轉移中圈定了初步的候選限界上下文。
然而，當我們圈出了「訂單上下文」與「履約上下文」之後，要如何進一步深入具體的業務場景，捕捉跨部門在溝通時那種最幽微、最具破壞力的**「同名異義詞（Polysemy）」**？
在下一篇中，我們將探討系統分析篇的第三大支柱：《抓出藏在句子裡的語義衝突：Domain Storytelling 如何用業務敘事提煉通用語言》，透過「誰用什麼做了什麼」的圖解敘事工法，徹底銳化出系統的純淨邊界。