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

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

“失效”的語(yǔ)言交流

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

讓我們看兩個(gè)例子：

上面的兩段對(duì)話發(fā)生在一次項(xiàng)目 Review 的過(guò)程中。通過(guò)第一個(gè)對(duì)話，我們能看出不同的角色在溝通的時(shí)候遇到了障礙；通過(guò)第二個(gè)對(duì)話說(shuō)明即便是相同的角色，溝通在某種程度也遇到了障礙。

軟件研發(fā)的困境

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

大家想一想，在哪一個(gè)階段暴露了最多的問(wèn)題？

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

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

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

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

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

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

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

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

二 Event Storming

Event Storming 介紹

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

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

Event Storming 語(yǔ)法

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

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

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

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

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

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

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

準(zhǔn)備 Event Storming

在開(kāi)始 ES 前，先做好準(zhǔn)備：

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

Event Storming 的過(guò)程

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

開(kāi)場(chǎng)介紹

在 ES 中有一個(gè)特殊的角色叫做 Facilitator（推動(dòng)者），一般是 ES 的組織者。在 ES 開(kāi)始前，Facilitator 向大家介紹 ES 是什么，有什么好處，以及彩色貼紙的用法。然后介紹討論的范圍和目標(biāo)。

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

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

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

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

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

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

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

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

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

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

例如“活動(dòng)已提交”事件：

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

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

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

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

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

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

講故事

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

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

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

Event Storming 常見(jiàn)問(wèn)題

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

Q：ES 通常邀請(qǐng)多少人參加？我需要邀請(qǐng)所有角色嗎？

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

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

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

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

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

Event Storming 小結(jié)

下面的四個(gè)圖直觀的解釋了 ES 的作用：

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

總的來(lái)說(shuō)，ES 讓不同的角色用同一種語(yǔ)言（彩色貼紙）從全局對(duì)業(yè)務(wù)達(dá)成共識(shí)。

四 從 ES 到代碼

簡(jiǎn)單介紹下 ES 如何順暢過(guò)渡到 DDD（Domain-Driven Design 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）。

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

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

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

提煉模型

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

從模型到實(shí)現(xiàn)

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

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

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

四 總結(jié)

ES 的價(jià)值在于：不同角色在具體業(yè)務(wù)場(chǎng)景下用一種共同語(yǔ)言（彩色貼紙）進(jìn)行交流，通過(guò)不斷提問(wèn)觸發(fā)探索、討論，最終達(dá)成真正共識(shí)。

阿里巴巴研發(fā)效能峰會(huì) | 架構(gòu)設(shè)計(jì)與代碼智能專場(chǎng)

6 月 13 日，阿里巴巴研發(fā)效能峰會(huì)架構(gòu)設(shè)計(jì)與代碼智能專場(chǎng)將圍繞領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、代碼可測(cè)試性、代碼智能、代碼數(shù)據(jù)打標(biāo)等技術(shù)，探討如何從架構(gòu)設(shè)計(jì)和機(jī)器智能方面讓代碼更加容易被編寫和維護(hù)。

點(diǎn)擊”閱讀原文“立即參與！

總結(jié)

以上是生活随笔為你收集整理的业务理解有偏差，产品和开发如何达成共识？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。