一 軟體研發的困境
“失效”的語言交流
日常研發過程中不同角色經常需要進行各種交流：溝通業務需求、讨論産品原型、讨論設計方案等。每個環節不同角色反複溝通，這是研發過程非常重要的環節。但問題是：我們花費大量時間溝通，真的“說” 清楚了嗎？
讓我們看兩個例子：
上面的兩段對話發生在一次項目 Review 的過程中。通過第一個對話，我們能看出不同的角色在溝通的時候遇到了障礙；通過第二個對話說明即便是相同的角色，溝通在某種程度也遇到了障礙。
軟體研發的困境
無論傳統的瀑布流程還是靈活模式，軟體研發總體上能劃分成幾個階段：提出需求，産品設計，研發，測試，最後上線。不同階段會産出不同傳遞物，有些比較簡單，也有些比較詳盡：MRD，PRD，技術方案，驗收方案等。在整個過程中，我們還會組織不同會議，或者是線下讨論。
大家想一想，在哪一個階段暴露了最多的問題？
不管我們多麼期望在早期發現問題，然而現實是越到研發晚期越會暴露更多問題。當産品進入測試階段，當上線後真實資料開始跑起來，當業務同學開始使用産品，這時候問題會像泉水一樣主動湧現出來，使用者會回報各種問題：“這個不是我想要的功能”，“XX 和我的預期不一樣”等等。通常在軟體研發的後期發現很多這種類似的問題。軟體研發發展到今天，這個問題依然沒有被很好的解決。
阻礙産品正确傳遞的原因
我們通過下面一個例子來分析什麼原因阻礙了産品的正确傳遞。
當産品同學提出需求的時候，研發同學做了好的回應，但實際上雙方想的内容并不一緻，這種情況我們稱之為表面一緻；當産品上線後，産品同學提出需求疑問時，研發同學的回答充滿了各種技術行話：定時系統，原子性等。顯然大部分産品同學不能了解這些技術行話，對話進入停滞狀态，我們稱這種現象為溝通障礙。在軟體研發中該問題反複的出現：溝通不暢阻礙了産品價值的正确傳遞。在不同角色進行交流時，三個原因阻礙了溝通的順暢進行：
- 得到的資訊不同：産品同學和業務同學關注的是業務需求，市場情況，近中遠期規劃，以及營運資料等；開發同學關注的是一個個具體的需求清單，功能點，是實作層次的細節資訊。
- 思維方式不同：産品同學關注業務/需求的合理性，産品邏輯，使用者體驗；而開發同學關注方案的可行性，實施成本，系統穩定性等。
- 溝通語言不同：産品同學用描述性的語言，語言的模糊會導緻不同角色了解的不同；而開發同學習慣使用技術語言，SDK、資料庫、一緻性等。不同角色交流的時候，會因為語言不相容，溝通不到一起去。
由于以上的原因，溝通容易陷入“雞同鴨講”的窘境：讨論很熱烈，甚至能取得表面的一緻，實際并沒有“說”清楚。
洞察軟體研發困境
Event Storming 方法的發明者 Alberto Brandolini 認為：産品展現了程式員對業務的了解（或誤解）。很多時候溝通失敗導緻的誤解進入産品實作。于是真正的業務需求在産品中沒有得到展現。溝通失敗是軟體研發的一個痛點，有待解決。
二 Event Storming
Event Storming 介紹
Event Storming（ES）：由不同角色共同參與，用彩色貼紙進行交流的工作坊。
如上圖，一群同學圍繞一個業務場景，用貼紙進行交流，這就是 ES 工作坊。通過貼紙進行交流，讓大家用同一種溝通語言，同一個思維方式，讓大家的思維在一個頻道上，這是 ES 的形式，也是 ES 的目的。
Event Storming 文法
ES 定義了一套彩色貼紙的“文法”：不同顔色的貼紙都有定義。淺黃色代表 Actor (角色)、藍色表示 Command (指令)、粉色代表 Policy (業務規則)、淺粉色代表System（系統）、橙色代表 Event (事件)，淺綠色表示 Read Model (讀模型)、紅色代表 HotSpot (熱點/問題)。
用 ES 的文法表達使用者的下單流程：買家 (淺黃色貼紙) 送出訂單（藍色貼紙），如果訂單裡商品是線上狀态，購買量小于商品庫存量 (粉色貼紙 Policy) ，那麼訂單建立成功（橙色事件貼紙），已建立的訂單 (綠色貼紙) 展示給使用者。訂單建立後需要通知買家（業務規則，粉色貼紙），系統執行發送站内信（藍色貼紙）。
二 如何在業務中使用 ES
下面我們通過一個業務場景（優惠券的投放和使用）介紹如何使用 ES。
業務背景介紹
電商網站提供各種優惠券：滿減券，折扣券，有無門檻券。
下圖描述電商營運小二在活動中投放優惠券的整體流程：小二先建立優惠券，然後再建立一個活動，把優惠券和活動關聯起來。活動通過公司财務的審批後才可釋出上線。消費者在活動頁面領取優惠券，在下單流程使用優惠券抵消金額。最後活動結束時要對整體活動的資料進行統計分析。
準備 Event Storming
在開始 ES 前，先做好準備：
- 準備物料：彩色貼紙、筆紙、一個足夠大的房間等。房間裡不要有椅子，因為在 ES 過程中，我們希望大家都全神貫注的投入，而不是坐在椅子上開始放松。
- 邀請正确的人：有問題的人和有答案的人。程式員、互動設計師、測試等都是有問題的人，需要通過 ES 了解業務和産品；有答案的人通常是使用者、業務或産品，他們通常能回答業務的背景，訴求和目标。
Event Storming 的過程
ES 可以分為開場介紹、ES 溝通業務和講故事三個階段。
開場介紹
在 ES 中有一個特殊的角色叫做 Facilitator（推動者），一般是 ES 的組織者。在 ES 開始前，Facilitator 向大家介紹 ES 是什麼，有什麼好處，以及彩色貼紙的用法。然後介紹讨論的範圍和目标。
比如，今天讨論優惠券場景，目标是理清營銷活動過程中優惠券的業務流程。最後 Facilitator 強調 ES 的規則：所有的讨論都寫在貼紙上；不允許使用電腦，手機；也不允許坐下。在 ES 的後續過程中，Facilitator 還需要承擔另外兩個重要職責：保持參與者的專注，通過提問驅動交流。
ES 的方式溝通業務
第一步先梳理事件（橙色貼紙）: 事件是已發生且重要的事情。事件必須是既成事實，且業務關注的事情。通常 Facilitator 會先準備第一個事件（可以是系統中任一事件）， 然後把它貼到牆上。
假設第一個事件是：優惠券已領取。接下來 Facilitator 通過提問引導大家找到更多的事件：
- 事件發生前有哪些事件（“優惠券已領取”前須先有“活動已釋出”事件）？
- 事件發生後下一個事件是什麼（“優惠券已領取”後有“優惠券已使用”，“優惠券已過期”等事件）？
提問會引導參與 ES 的同學将新發現的事件不斷補充到牆上。事件要保持整體的時間順序：先發生的事情貼在左邊，後發生的事情在右邊。通常大家容易關注系統的正常流程，也就是 Happy path。這時候 Facilitator 需要引導大家關注業務的非正常流程 Unhappy path。邊界條件，異常情況通常是業務複雜性的重要原因，也是非常容易被忽視的部分。
- 事件一定會發生嗎（優惠券一定領取成功嗎？不是，貼上“優惠券領取失敗”事件）？
追問 unhappy path 梳理出業務的完整視圖，當大家發現新事件的速度接近停滞的時候，就應進入梳理業務規則的階段了。
Policy，業務邏輯或規則，這是業務中最重要的部分。Facilitator 會提出以下問題：
- 事件是否一定成功？如果不是，那麼成功的前提條件是什麼？
- 該事件是否會導緻其他事件的發生（Reaction）？
例如“活動已送出”事件：
- 活動送出成功的前提條件：活動已關聯有效優惠券，且已選擇了生效方式，并且選擇了适用人群。
- 活動送出後，會導緻稽核任務已建立事件，這裡的業務規則是：活動送出或需建立稽核任務。
接下來找出三個角色：Actor (和系統互動的人)，Command (使用者動作) 和 Read Model (輔助使用者決策的工具)。Facilitator 提出以下問題：
- 是什麼觸發了事件？即事件發生的原因 (ES 的文法：when Event， then Command)。
- 誰執行了動作。是人，系統，還是時間（例如定時觸發的事件）？
- 做出動作前，使用者需要擷取哪些資訊？
以上的問題會引導大家找到 Actor, command 和 Read Model。 在營銷活動已送出事件中：小二（Actor）執行了送出活動（Command）, 進而産生了“活動已送出”事件。
最後介紹 Hotspot：業務痛點、瓶頸、模糊點。Hotspot 是 ES 過程中随時都應該發現并記錄下來的。Facilitator 可以引導大家發現業務中未描叙到的問題，例如：使用者使用優惠券進行支付的場景中，如果使用者支付失敗，已使用的優惠券該如何處理呢？優惠券應該返還給使用者，還是不做處理？通過提出這樣的問題，引導大家對業務流程進行更深入的讨論。通常在 ES 的過程中，識别并記錄 Hotspot，不要在 ES 中嘗試解決所有的 hotspot。
以上介紹了 ES 的主要元素：Event，Policy，Actor，Command，Read Model，Hotspot。用 ES 描述了優惠券發放的業務流程，最後一步是“講故事” (storytelling) 的階段。
講故事
Facilitator 邀請不同的人擔任志願者，每個志願者講一段故事：按時間順序和 ES 描叙的邏輯， 向其他人介紹業務流程。過程中，聽衆注意到不一緻的地方随時提出問題，大家讨論問題，通過增加/删除/移動貼紙來修複問題，并繼續講故事的流程。
最開始大家會按時間正序講故事，最後大家還可以倒序講故事。梳理業務的異常場景，倒序講故事的方法更有效。例如為什麼會發生“優惠券領取失敗”事件，事件的原因是 balabala…
經過講故事階段的完善，大家獲得了業務的完整了解，這時候可以結束讨論，儲存相關材料，遺留下來的 Hotspot 交由相關同學跟進。
Event Storming 常見問題
ES 比其他方式更能幫助大家順暢的溝通，但是對于首次參與或組織 ES 的同學也有一些疑問。 以下列出一些常見問題：
Q：ES 通常邀請多少人參加？我需要邀請所有角色嗎？
A：不一定。ES 鼓勵不同角色共同參與，但是參與人的态度更重要，積極主動參與是 ES 成功的關鍵。通常一個 Pizza (8 - 10人) 的規模，是适合 ES 人數。
Q：我的業務場景和複雜，在 ES 中要梳理完整個業務流程嗎？
A: 不需要。ES 需要大家高度參與，是以需要控制好時間。每次 ES 的範圍選擇複雜業務場景的一部分，保證 ES 的效果。
Q：我應該在什麼階段做 ES？
A：項目的任何階段都可以做 ES。ES 既可用于梳理業務現狀，也可以用于設計業務的未來方案。
Event Storming 小結
下面的四個圖直覺的解釋了 ES 的作用：
- 圖 1，說明不同角色通過語言交流，雖然達成表面一緻，實際上大家了解不一緻。
- 圖 2，ES 要求大家通過貼紙的形式可視化出來腦海中的想法，進而使分歧自動顯現。
- 圖 3，ES 通過不斷的提問觸發讨論，進而能夠拉通認知，消除分歧點和模糊點。
- 圖 4，ES 拉通了大家對業務的了解，進而達成了真正的共識。
總的來說，ES 讓不同的角色用同一種語言（彩色貼紙）從全局對業務達成共識。
四 從 ES 到代碼
簡單介紹下 ES 如何順暢過渡到 DDD（Domain-Driven Design 領域驅動設計）。
提取業務概念
DDD 中最重要的是統一語言：交流使用統一語言；模型表達統一語言；代碼表達統一語言。語言是由概念組成的，ES 的過程已經将概念寫在貼紙上，并且在交流中反複使用。例如：優惠券，營銷活動，已領取優惠券，領取方式，人群等。
一部分概念有生命周期，并且有唯一的辨別符。例如：營銷活動，優惠券，已領取優惠券。這些就是 DDD 中的實體；還有一部分概念辨別一個完整的業務含義，但是沒有生命周期，并且屬性相同的兩個對象可以替換，這些對象就是 DDD 中的值對象，例如：領取方式，生效方式，人群。
提煉模型
概念和概念之間是有關系的。比如說，優惠券和營銷活動有關聯關系，已領取優惠券是在某個營銷活動下領取的，營銷活動也包含很多資訊，它的生效方式是什麼，領取方式是什麼，人群是誰。概念與概念之間的關系也就是領域模型。
從模型到實作
将 ES 貼紙重新組合：圍繞一個核心概念，将與該概念有關的 Event，Command，Policy 組合在一起。例如下圖左邊圍繞營銷活動為中心重新組織了貼紙（Command，Policy，Event），這些貼紙和右邊的代碼映射起來，這也就是 DDD 中說的代碼表達統一語言。到此，簡單介紹了如何從 ES 到概念，從概念到模型，以及模型和代碼實作是怎麼關聯起來的。
架構，代碼和限制
下圖簡單描述應用架構，代碼結構，以及如何通過 ArchUnit 實作架構限制。
四 總結
ES 的價值在于：不同角色在具體業務場景下用一種共同語言（彩色貼紙）進行交流，通過不斷提問觸發探索、讨論，最終達成真正共識。
阿裡巴巴研發效能峰會 | 架構設計與代碼智能專場
6 月 13 日，阿裡巴巴研發效能峰會架構設計與代碼智能專場将圍繞領域驅動設計、代碼可測試性、代碼智能、代碼資料打标等技術，探讨如何從架構設計和機器智能方面讓代碼更加容易被編寫和維護。
識别下方二維碼，或點選”
閱讀原文“立即參與：