一 軟件研發的困境
“失效”的語言交流
日常研發過程中不同角色經常需要進行各種交流：溝通業務需求、討論產品原型、討論設計方案等。每個環節不同角色反覆溝通，這是研發過程非常重要的環節。但問題是：我們花費大量時間溝通，真的“說” 清楚了嗎？
讓我們看兩個例子：
上面的兩段對話發生在一次項目 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 日，阿里巴巴研發效能峰會架構設計與代碼智能專場將圍繞領域驅動設計、代碼可測試性、代碼智能、代碼數據打標等技術，探討如何從架構設計和機器智能方面讓代碼更加容易被編寫和維護。
識別下方二維碼，或點擊”閱讀原文“立即參與：
