事件風暴過程全體驗 - 上篇

故事背景

場景源於一個打劫案件，當劫匪拿出他的槍，來自未來的超能攝像頭髮現危險馬上自動報警。同時，各位正義英雄暗地裏開始出動！

哪知道這班劫匪也不是蓋的，某正義英雄（請自動腦補蝙蝠俠）雖然第一個到場，和劫匪激戰一輪居然也還沒拿下，無奈中只能觸發身上的升級預警裝置通知總部增援。

這裏用一個簡化版的用戶旅程地圖描述了這個場景。通常地，類似的用戶旅程就正是掀起事件風暴的優秀開端～

現在讓我們假設，作爲英雄總部，我們計劃基於這個場景構建一個自動預警系統，從而讓整個預警過程更加智能更加順暢，那我們 IT 民工該怎麼和總部一起設計這個系統呢？

當開啓事件風暴，第一件事情是必須把自己的視角切換到自動預警系統的設計師這個角色上來，謹記，我們關注的是這個系統在這個場景下應該怎麼運作，系統以外的細節我們可以暫且忽略。換而言之，“自動預警” 就應該是核心域。

在正統的事件風暴過程中：

• 第一步就是尋找事件並以 “XX 已 YY”（如 “訂單已提交”）完成時態描述這個事件

• 第二步就是尋找這個事件對應的命令，通常是一個動賓結構（如 “提交訂單”）

• 角色 簡單來說就是主語，可以是人物，可以是類似於定時任務的規則，可以是外部系統

• 讀模型 （Optional）角色是基於什麼信息做之後的決定的，不一定每步都有

• 決策 / 命令 原譯 Command，但叫 “業務決策” 可能更好理解，反正就是描述做了什麼決定

• 事件 描述之前的決定觸發了什麼事情，或者說決策導致某東西的狀態變了爲什麼。

當然，如果在做的過程中發現這樣連起來想不清楚，那就還原基本步，按照原來的事件 -> 命令這樣小步走就好了.

下面是我自己設計的命令風暴，結果跟大家在互動區設計的還是差不多的。（我這個貼法跟正宗的有點不一樣，主要是爲了糊牆的時候省地方）

風暴中，有 “預警通知”、“警報”、“升級預警通知”，有童鞋會問是不是可以統一叫“通知”，這個其實也是統一語言和對業務的理解問題，如果覺得三個場景都是發送一樣的通知就可以了，那統一叫“預警通知” 是個不錯的選擇，但如果希望每次發送的內容都不一樣，那還是得取個不一樣的名字方便後續辨認區分。

過程中，比如開會怎麼商量，作戰計劃怎麼執行，這些其實不是這個預警系統關注的事情，所以不需要進一步展開.

Step 2. 識別業務對象

簡單來說，就是要找出之前那個” 決策 / 命令 “打算要操作什麼東西？或者說那個 “事件” 裏面“XX 已 YY“的 XX 說的是什麼。

如果第一步是嚴格按照 “XX 已 YY” 的寫法進行，這裏應該難度不是特別大。

當然，如果在第一步裏面把一些查詢或者打開頁面這類的動作也放進命令風暴的話，有可能那些步驟會找不出一個業務對象，或者就成爲 “XX 頁面”。這也是爲什麼通常在命令風暴中不考慮一些查詢動作的原因，打開頁面的動作並沒有實際改變什麼東西的狀態。

Step3. 分析業務對象生命週期

在通常的事件風暴介紹中，“分析生命週期” 經常就是一句話帶過，但這裏我會建議大家顯式地把生命週期畫出來，這樣對於後續分辨聚合根 / 實體 / 值對象會很有幫助。

有一些信息只出現了一次，所以畫出來就成了一個點，明顯的這些可以先歸爲值對象，因爲他們只是某個值，而沒有生命週期，不需要 id 之類的標識。

另一類是一條線段，可見他們是有生命週期的，期間是帶有狀態的，這些就是傳說中的實體了。

那哪些是聚合根呢？

• 簡單來看，就是看這些點和線的歸屬。比如上圖中，“案件記錄” 的生命週期是最長的，也包含了其他所有的業務對象生命週期，那看起來它就應該是聚合根。

• 再看 “警報升級會議”，看起來沒有案件就沒有它的存在，所以它應該是屬於“案件記錄” 這個聚合根裏面的一個實體，但如果我們擴展一下分析的場景，比如假設有另外一個場景是說在平常其實英雄也需要開例會，而且對應的也是一樣的創建 / 登入 / 登出 / 結束，我們覺得它們可以統一處理，那這樣 “會議” 就會是另外一個聚合

• 同理，“警報升級通知 “等的三個值對象，如果只在案件週期內存在，那他們就是隸屬於案件的值對象。但如果我們有其他場景是會比如配置這些通知的不同模版的， 那這些通知就有了自己的生命週期，可能自己會獨立成爲聚合根

所以，看生命週期還得全面的看，在集合了多個場景之後纔會比較準確。當然，裏面也會有一些業務常識在，比如 “會議” 如果一開始我們就選擇了 Zoom 之類的外部系統實現，那很明顯它就應該獨立出去自己聚合了。

Step4.

這裏第四步包括了兩部分：聚合細化 & 上下文分析，這兩部分其實是相輔相成的，並沒有絕對的順序，有時候還會根據其中一步的分析結果來回調整另一步，所以這裏我把它們歸到一起。

Step4a. 細化聚合根分析

這裏我們先假設，會議有其他場景也用到，所以它屬於另一個聚合。

那下面我們就可以把上面的業務對象按照聚合的方式細化分析他們之間的關係了。並可以補充上一些關鍵的屬性

Step4b. 識別上下文和調用關係

同理也可以劃分出上下文以及他們之間的調用關係。（這裏的 U 我是指消費者 / 調用方，而 D 是生產者 / 被調用方）

留意，這裏說的是上下文，也就是業務邊界，它跟服務劃分並沒有絕對的關係。

要問如果對應到服務劃分，其實我們還得多看幾個維度綜合考慮，比如：

• 組織架構（康威定律）- 比如上面預警系統如果都是一個團隊管，那會議和案件不太複雜的時候放在一個服務也不是不可以，但如果分別兩個團隊管，那還是分開好，免得吵架。

• 業務邊界（上下文）

• 變更頻率 - 比如營銷活動上下文裏面有營銷活動的規則，活動的元素基本固定，但活動規則經常變，這樣我們可以考慮從活動上下文中再分出活動規則

• 高併發、低延時等的非功能性需求 - 比如某些高併發場景需要讀寫分離，那就會把一個上下文再拆開讀和寫兩部分

• 技術層面需求 - 比如因某些特性需要用不同的語言編寫

• 安全等其他層面要求

至此，從用戶旅程的一個場景，到業務領域的劃分就完成了 ^_^

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rpofTb88qLNKhBZaMhg6cQ