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

一 軟件研發(fā)的困境

“失效”的語言交流

日常研發(fā)過程中不同角色經(jīng)常需要進行各種交流：溝通業(yè)務(wù)需求、討論產(chǎn)品原型、討論設(shè)計方案等。每個環(huán)節(jié)不同角色反復(fù)溝通，這是研發(fā)過程非常重要的環(huán)節(jié)。但問題是：我們花費大量時間溝通，真的“說” 清楚了嗎?

讓我們看兩個例子：

?

??

上面的兩段對話發(fā)生在一次項目 Review 的過程中。通過第一個對話，我們能看出不同的角色在溝通的時候遇到了障礙;通過第二個對話說明即便是相同的角色，溝通在某種程度也遇到了障礙。

軟件研發(fā)的困境

無論傳統(tǒng)的瀑布流程還是敏捷模式，軟件研發(fā)總體上能劃分成幾個階段：提出需求，產(chǎn)品設(shè)計，研發(fā)，測試，最后上線。不同階段會產(chǎn)出不同交付物，有些比較簡單，也有些比較詳盡：MRD，PRD，技術(shù)方案，驗收方案等。在整個過程中，我們還會組織不同會議，或者是線下討論。

?

??

大家想一想，在哪一個階段暴露了最多的問題?

不管我們多么期望在早期發(fā)現(xiàn)問題，然而現(xiàn)實是越到研發(fā)晚期越會暴露更多問題。當產(chǎn)品進入測試階段，當上線后真實數(shù)據(jù)開始跑起來，當業(yè)務(wù)同學(xué)開始使用產(chǎn)品，這時候問題會像泉水一樣主動涌現(xiàn)出來，用戶會反饋各種問題：“這個不是我想要的功能”，“XX 和我的預(yù)期不一樣”等等。通常在軟件研發(fā)的后期發(fā)現(xiàn)很多這種類似的問題。軟件研發(fā)發(fā)展到今天，這個問題依然沒有被很好的解決。

阻礙產(chǎn)品正確交付的原因

我們通過下面一個例子來分析什么原因阻礙了產(chǎn)品的正確交付。

?

??

當產(chǎn)品同學(xué)提出需求的時候，研發(fā)同學(xué)做了好的回應(yīng)，但實際上雙方想的內(nèi)容并不一致，這種情況我們稱之為表面一致;當產(chǎn)品上線后，產(chǎn)品同學(xué)提出需求疑問時，研發(fā)同學(xué)的回答充滿了各種技術(shù)行話：定時系統(tǒng)，原子性等。顯然大部分產(chǎn)品同學(xué)不能理解這些技術(shù)行話，對話進入停滯狀態(tài)，我們稱這種現(xiàn)象為溝通障礙。在軟件研發(fā)中該問題反復(fù)的出現(xiàn)：溝通不暢阻礙了產(chǎn)品價值的正確交付。在不同角色進行交流時，三個原因阻礙了溝通的順暢進行：

?

??

• 得到的信息不同：產(chǎn)品同學(xué)和業(yè)務(wù)同學(xué)關(guān)注的是業(yè)務(wù)需求，市場情況，近中遠期規(guī)劃，以及運營數(shù)據(jù)等;開發(fā)同學(xué)關(guān)注的是一個個具體的需求列表，功能點，是實現(xiàn)層次的細節(jié)信息。
• 思維方式不同：產(chǎn)品同學(xué)關(guān)注業(yè)務(wù)/需求的合理性，產(chǎn)品邏輯，用戶體驗;而開發(fā)同學(xué)關(guān)注方案的可行性，實施成本，系統(tǒng)穩(wěn)定性等。
• 溝通語言不同：產(chǎn)品同學(xué)用描述性的語言，語言的模糊會導(dǎo)致不同角色理解的不同;而開發(fā)同學(xué)習(xí)慣使用技術(shù)語言，SDK、數(shù)據(jù)庫、一致性等。不同角色交流的時候，會因為語言不相容，溝通不到一起去。

由于以上的原因，溝通容易陷入“雞同鴨講”的窘境：討論很熱烈，甚至能取得表面的一致，實際并沒有“說”清楚。

洞察軟件研發(fā)困境

Event Storming 方法的發(fā)明者 Alberto Brandolini 認為：產(chǎn)品體現(xiàn)了程序員對業(yè)務(wù)的理解(或誤解)。很多時候溝通失敗導(dǎo)致的誤解進入產(chǎn)品實現(xiàn)。于是真正的業(yè)務(wù)需求在產(chǎn)品中沒有得到體現(xiàn)。溝通失敗是軟件研發(fā)的一個痛點，有待解決。

?

??

二 Event Storming

Event Storming 介紹

Event Storming(ES)：由不同角色共同參與，用彩色貼紙進行交流的工作坊。

?

??

如上圖，一群同學(xué)圍繞一個業(yè)務(wù)場景，用貼紙進行交流，這就是 ES 工作坊。通過貼紙進行交流，讓大家用同一種溝通語言，同一個思維方式，讓大家的思維在一個頻道上，這是 ES 的形式，也是 ES 的目的。

Event Storming 語法

ES 定義了一套彩色貼紙的“語法”：不同顏色的貼紙都有定義。淺黃色代表 Actor (角色)、藍色表示 Command (命令)、粉色代表 Policy (業(yè)務(wù)規(guī)則)、淺粉色代表System(系統(tǒng))、橙色代表 Event (事件)，淺綠色表示 Read Model (讀模型)、紅色代表 HotSpot (熱點/問題)。

?

??

用 ES 的語法表達用戶的下單流程：買家 (淺黃色貼紙) 提交訂單(藍色貼紙)，如果訂單里商品是在線狀態(tài)，購買量小于商品庫存量 (粉色貼紙 Policy) ，那么訂單創(chuàng)建成功(橙色事件貼紙)，已創(chuàng)建的訂單 (綠色貼紙) 展示給用戶。訂單創(chuàng)建后需要通知買家(業(yè)務(wù)規(guī)則，粉色貼紙)，系統(tǒng)執(zhí)行發(fā)送站內(nèi)信(藍色貼紙)。

?

??

如何在業(yè)務(wù)中使用 ES

下面我們通過一個業(yè)務(wù)場景(優(yōu)惠券的投放和使用)介紹如何使用 ES。

業(yè)務(wù)背景介紹

電商網(wǎng)站提供各種優(yōu)惠券：滿減券，折扣券，有無門檻券。

?

??

下圖描述電商運營小二在活動中投放優(yōu)惠券的整體流程：小二先創(chuàng)建優(yōu)惠券，然后再創(chuàng)建一個活動，把優(yōu)惠券和活動關(guān)聯(lián)起來?；顒油ㄟ^公司財務(wù)的審批后才可發(fā)布上線。消費者在活動頁面領(lǐng)取優(yōu)惠券，在下單流程使用優(yōu)惠券抵消金額。最后活動結(jié)束時要對整體活動的數(shù)據(jù)進行統(tǒng)計分析。

?

??

準備 Event Storming

在開始 ES 前，先做好準備：

?

??

• 準備物料：彩色貼紙、筆紙、一個足夠大的房間等。房間里不要有椅子，因為在 ES 過程中，我們希望大家都全神貫注的投入，而不是坐在椅子上開始放松。
• 邀請正確的人：有問題的人和有答案的人。程序員、交互設(shè)計師、測試等都是有問題的人，需要通過 ES 理解業(yè)務(wù)和產(chǎn)品;有答案的人通常是用戶、業(yè)務(wù)或產(chǎn)品，他們通常能回答業(yè)務(wù)的背景，訴求和目標。

Event Storming 的過程

ES 可以分為開場介紹、ES 溝通業(yè)務(wù)和講故事三個階段。

開場介紹

在 ES 中有一個特殊的角色叫做 Facilitator(推動者)，一般是 ES 的組織者。在 ES 開始前，F(xiàn)acilitator 向大家介紹 ES 是什么，有什么好處，以及彩色貼紙的用法。然后介紹討論的范圍和目標。

比如，今天討論優(yōu)惠券場景，目標是理清營銷活動過程中優(yōu)惠券的業(yè)務(wù)流程。最后 Facilitator 強調(diào) ES 的規(guī)則：所有的討論都寫在貼紙上;不允許使用電腦，手機;也不允許坐下。在 ES 的后續(xù)過程中，F(xiàn)acilitator 還需要承擔(dān)另外兩個重要職責(zé)：保持參與者的專注，通過提問驅(qū)動交流。

?

??

ES 的方式溝通業(yè)務(wù)

第一步先梳理事件(橙色貼紙): 事件是已發(fā)生且重要的事情。事件必須是既成事實，且業(yè)務(wù)關(guān)注的事情。通常 Facilitator 會先準備第一個事件(可以是系統(tǒng)中任一事件)， 然后把它貼到墻上。

?

??

假設(shè)第一個事件是：優(yōu)惠券已領(lǐng)取。接下來 Facilitator 通過提問引導(dǎo)大家找到更多的事件：

• 事件發(fā)生前有哪些事件(“優(yōu)惠券已領(lǐng)取”前須先有“活動已發(fā)布”事件)?
• 事件發(fā)生后下一個事件是什么(“優(yōu)惠券已領(lǐng)取”后有“優(yōu)惠券已使用”，“優(yōu)惠券已過期”等事件)?

提問會引導(dǎo)參與 ES 的同學(xué)將新發(fā)現(xiàn)的事件不斷補充到墻上。事件要保持整體的時間順序：先發(fā)生的事情貼在左邊，后發(fā)生的事情在右邊。通常大家容易關(guān)注系統(tǒng)的正常流程，也就是 Happy path。這時候 Facilitator 需要引導(dǎo)大家關(guān)注業(yè)務(wù)的非正常流程 Unhappy path。邊界條件，異常情況通常是業(yè)務(wù)復(fù)雜性的重要原因，也是非常容易被忽視的部分。

• 事件一定會發(fā)生嗎(優(yōu)惠券一定領(lǐng)取成功嗎?不是，貼上“優(yōu)惠券領(lǐng)取失敗”事件)?

追問 unhappy path 梳理出業(yè)務(wù)的完整視圖，當大家發(fā)現(xiàn)新事件的速度接近停滯的時候，就應(yīng)進入梳理業(yè)務(wù)規(guī)則的階段了。

Policy，業(yè)務(wù)邏輯或規(guī)則，這是業(yè)務(wù)中最重要的部分。Facilitator 會提出以下問題：

• 事件是否一定成功?如果不是，那么成功的前提條件是什么?
• 該事件是否會導(dǎo)致其他事件的發(fā)生(Reaction)?

例如“活動已提交”事件：

• 活動提交成功的前提條件：活動已關(guān)聯(lián)有效優(yōu)惠券，且已選擇了生效方式，并且選擇了適用人群。
• 活動提交后，會導(dǎo)致審核任務(wù)已創(chuàng)建事件，這里的業(yè)務(wù)規(guī)則是：活動提交或需創(chuàng)建審核任務(wù)。

?

??

接下來找出三個角色：Actor (和系統(tǒng)交互的人)，Command (用戶動作) 和 Read Model (輔助用戶決策的工具)。Facilitator 提出以下問題：

• 是什么觸發(fā)了事件?即事件發(fā)生的原因 (ES 的語法：when Event， then Command)。
• 誰執(zhí)行了動作。是人，系統(tǒng)，還是時間(例如定時觸發(fā)的事件)?
• 做出動作前，用戶需要獲取哪些信息?

以上的問題會引導(dǎo)大家找到 Actor, command 和 Read Model。 在營銷活動已提交事件中：小二(Actor)執(zhí)行了提交活動(Command), 從而產(chǎn)生了“活動已提交”事件。

?

??

最后介紹 Hotspot：業(yè)務(wù)痛點、瓶頸、模糊點。Hotspot 是 ES 過程中隨時都應(yīng)該發(fā)現(xiàn)并記錄下來的。Facilitator 可以引導(dǎo)大家發(fā)現(xiàn)業(yè)務(wù)中未描敘到的問題，例如：用戶使用優(yōu)惠券進行支付的場景中，如果用戶支付失敗，已使用的優(yōu)惠券該如何處理呢?優(yōu)惠券應(yīng)該返還給用戶，還是不做處理?通過提出這樣的問題，引導(dǎo)大家對業(yè)務(wù)流程進行更深入的討論。通常在 ES 的過程中，識別并記錄 Hotspot，不要在 ES 中嘗試解決所有的 hotspot。

?

??

以上介紹了 ES 的主要元素：Event，Policy，Actor，Command，Read Model，Hotspot。用 ES 描述了優(yōu)惠券發(fā)放的業(yè)務(wù)流程，最后一步是“講故事” (storytelling) 的階段。

講故事

Facilitator 邀請不同的人擔(dān)任志愿者，每個志愿者講一段故事：按時間順序和 ES 描敘的邏輯， 向其他人介紹業(yè)務(wù)流程。過程中，聽眾注意到不一致的地方隨時提出問題，大家討論問題，通過增加/刪除/移動貼紙來修復(fù)問題，并繼續(xù)講故事的流程。

最開始大家會按時間正序講故事，最后大家還可以倒序講故事。梳理業(yè)務(wù)的異常場景，倒序講故事的方法更有效。例如為什么會發(fā)生“優(yōu)惠券領(lǐng)取失敗”事件，事件的原因是 balabala…

經(jīng)過講故事階段的完善，大家獲得了業(yè)務(wù)的完整理解，這時候可以結(jié)束討論，保存相關(guān)材料，遺留下來的 Hotspot 交由相關(guān)同學(xué)跟進。

?

??

Event Storming 常見問題

ES 比其他方式更能幫助大家順暢的溝通，但是對于首次參與或組織 ES 的同學(xué)也有一些疑問。 以下列出一些常見問題：

Q：ES 通常邀請多少人參加?我需要邀請所有角色嗎?

A：不一定。ES 鼓勵不同角色共同參與，但是參與人的態(tài)度更重要，積極主動參與是 ES 成功的關(guān)鍵。通常一個 Pizza (8 - 10人) 的規(guī)模，是適合 ES 人數(shù)。

Q：我的業(yè)務(wù)場景和復(fù)雜，在 ES 中要梳理完整個業(yè)務(wù)流程嗎?

A: 不需要。ES 需要大家高度參與，因此需要控制好時間。每次 ES 的范圍選擇復(fù)雜業(yè)務(wù)場景的一部分，保證 ES 的效果。

Q：我應(yīng)該在什么階段做 ES?

A：項目的任何階段都可以做 ES。ES 既可用于梳理業(yè)務(wù)現(xiàn)狀，也可以用于設(shè)計業(yè)務(wù)的未來方案。

Event Storming 小結(jié)

下面的四個圖直觀的解釋了 ES 的作用：

?

??

• 圖 1，說明不同角色通過語言交流，雖然達成表面一致，實際上大家理解不一致。
• 圖 2，ES 要求大家通過貼紙的形式可視化出來腦海中的想法，從而使分歧自動顯現(xiàn)。
• 圖 3，ES 通過不斷的提問觸發(fā)討論，從而能夠拉通認知，消除分歧點和模糊點。
• 圖 4，ES 拉通了大家對業(yè)務(wù)的理解，從而達成了真正的共識。

總的來說，ES 讓不同的角色用同一種語言(彩色貼紙)從全局對業(yè)務(wù)達成共識。

從 ES 到代碼

簡單介紹下 ES 如何順暢過渡到 DDD(Domain-Driven Design 領(lǐng)域驅(qū)動設(shè)計)。

提取業(yè)務(wù)概念

DDD 中最重要的是統(tǒng)一語言：交流使用統(tǒng)一語言;模型表達統(tǒng)一語言;代碼表達統(tǒng)一語言。語言是由概念組成的，ES 的過程已經(jīng)將概念寫在貼紙上，并且在交流中反復(fù)使用。例如：優(yōu)惠券，營銷活動，已領(lǐng)取優(yōu)惠券，領(lǐng)取方式，人群等。

一部分概念有生命周期，并且有唯一的標識符。例如：營銷活動，優(yōu)惠券，已領(lǐng)取優(yōu)惠券。這些就是 DDD 中的實體;還有一部分概念標識一個完整的業(yè)務(wù)含義，但是沒有生命周期，并且屬性相同的兩個對象可以替換，這些對象就是 DDD 中的值對象，例如：領(lǐng)取方式，生效方式，人群。

?

??

提煉模型

概念和概念之間是有關(guān)系的。比如說，優(yōu)惠券和營銷活動有關(guān)聯(lián)關(guān)系，已領(lǐng)取優(yōu)惠券是在某個營銷活動下領(lǐng)取的，營銷活動也包含很多信息，它的生效方式是什么，領(lǐng)取方式是什么，人群是誰。概念與概念之間的關(guān)系也就是領(lǐng)域模型。

?

??

從模型到實現(xiàn)

將 ES 貼紙重新組合：圍繞一個核心概念，將與該概念有關(guān)的 Event，Command，Policy 組合在一起。例如下圖左邊圍繞營銷活動為中心重新組織了貼紙(Command，Policy，Event)，這些貼紙和右邊的代碼映射起來，這也就是 DDD 中說的代碼表達統(tǒng)一語言。到此，簡單介紹了如何從 ES 到概念，從概念到模型，以及模型和代碼實現(xiàn)是怎么關(guān)聯(lián)起來的。

?

??

架構(gòu)，代碼和約束

下圖簡單描述應(yīng)用架構(gòu)，代碼結(jié)構(gòu)，以及如何通過 ArchUnit 實現(xiàn)架構(gòu)約束。

?

??

四 總結(jié)

ES 的價值在于：不同角色在具體業(yè)務(wù)場景下用一種共同語言(彩色貼紙)進行交流，通過不斷提問觸發(fā)探索、討論，最終達成真正共識。