在考慮如何對業務模型進行抽象從而建立領域模型之前，必須解決業務與產品、開發之間“溝通”的問題。如何讓業務人員和開發人員順暢溝通，在業務流程設計中不遺漏成敗攸關的業務場景?如何才能讓業務溝通的過程順暢過渡到架構設計、編碼乃至測試?阿里巴巴技術專家李建結合團隊的實際案例，分享了他們在使用 Event Storming(事件風暴) 進行領域建模時的經驗、收獲和思考。

一 軟件研發的困境

“失效”的語言交流

日常研發過程中不同角色經常需要進行各種交流：溝通業務需求、討論產品原型、討論設計方案等。每個環節不同角色反復溝通，這是研發過程非常重要的環節。但問題是：我們花費大量時間溝通，真的“說” 清楚了嗎?

讓我們看兩個例子：

?

??

上面的兩段對話發生在一次項目 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 的價值在于：不同角色在具體業務場景下用一種共同語言(彩色貼紙)進行交流，通過不斷提問觸發探索、討論，最終達成真正共識。