業務理解有誤差，產品和開發如何達成共識？

簡介： 在考慮如何對業務模型進行抽象從而創建領域模型以前，必須解決業務與產品、開發之間「溝通」的問題。如何讓業務人員和開發人員順暢溝通，在業務流程設計中不遺漏成敗攸關的業務場景？如何才能讓業務溝通的過程順暢過渡到架構設計、編碼乃至測試？阿里巴巴技術專家李建結合團隊的實際案例，分享了他們在使用 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 的價值在於：不一樣角色在具體業務場景下用一種共同語言（彩色貼紙）進行交流，經過不斷提問觸發探索、討論，最終達成真正共識。

阿里巴巴研發效能峯會 | 架構設計與代碼智能專場

6 月 13 日，阿里巴巴研發效能峯會架構設計與代碼智能專場將圍繞領域驅動設計、代碼可測試性、代碼智能、代碼數據打標等技術，探討如何從架構設計和機器智能方面讓代碼更加容易被編寫和維護。

點擊」閱讀原文「當即參與！