學習與嘗試 –> 事件風暴

• 2022 年 8 月 8 日
• 筆記
• 需求

事件風暴

1. 基礎概念

術語

1. 執行者 —–> 是指執行的角色，系統的主體，是導致系統狀態變化的觸發源
   1. 人員，系統的用戶，操作人員等
   2. 系統，系統本身執行的，或者調度的，自動觸發的 ，第三方系統
   3. 定時任務，定時的觸發任務
2. 命令 —–> 是執行者發起的操作，構成要件是執行者的行為
   1. 是某個場景中領域事件的觸發動作，對應一個用例
3. 領域對象 —–> 是對對象，人或者系統的資訊表示，它通過較為簡單的資訊結構來代表我們需要理解的複雜事務或系統
   1. 創建訂單，修改訂單 ，刪除訂單等 ，領域對象：訂單
4. 領域事件 —–> 是和領域相關的事情，實在業務上真實發生的事實，這些事件對系統會產生關鍵影響，是觀察業務系統變化的關鍵點，領域事件一般是領域專家關心的，一般已動詞的過去式表示，表示已發生什麼事件，是過去已經發生過的事實
   1. 識別領域事件的線索
      1. 是否產生了某種數據
      2. 系統狀態是否發生變化，無論這種狀態存放到資料庫還是記憶體
      3. 是否對外發送了某些消息
5. 讀模型 —–> 為了達到一個目的，需要在系統中讀出一些數據
   1. 讀模型來源於領域對象，展現的形式不一樣，一個讀模型中可能包含多個領域對象

2. 事件風暴工作坊實踐流程

• 產品願景，識別軟體價值和定位，進行業務的導入，團隊共識業務需求資訊
• 初步進行領域劃分，識別出核心域，分而治之 ，對問題域的初步劃分，分解問題
• 事件風暴，觀察業務系統變化的關鍵點，找出系統狀態的變化規律
• 命令風暴，找出系統狀態的觸發者和行為
• 尋找模型，根據領域名詞，設別領域對象，識別對象之間的關係，設計模型
• 限界上下文劃分，分解問題 ，戰略規劃
• 規範化的輸出，已團隊共識的模型或者UML輸出等

3. 步驟

1. 共識白板中的圖例，各自表示的是什麼

   

2. 從一個初步劃分的領域開始 ，按照時間軸，從左到右的，寫出事件（對時間的順序要求不是很高，盡量按照時間的先後順序識別）

3. 識別命令 ，和 執行者 ，並明確執行者的角色，比如，第三方系統，系統操作人員，定時任務

4. 識別讀模型

5. 根據業務識別出來的命令，事件，找出具有代表性的名詞，建立初步的模型，並整理分類

6. 識別模型之間的關係，畫出領域分析模型

7. 根據分析模型，細化模型，設計出領域設計模型，並用uml展示

8. 根據設計模型 設計 聚合，實體，值對象，細化模型

9. 劃分限界上下文 ，規範文檔輸出

業務需求

願景和目標，統一認識，對於目標的共識

對於 ：精裝管理業務流程的業務人員（銷售，訂單，財務）

他們想 ：更好的管理客戶，項目，訂單，以及更快的協作，完成訂單，跟蹤訂單

這個 ：精裝訂單系統

是一個 ：內部管理系統

它可以 ：通過對客戶，項目，訂單的在線化管理，提升業務方的協作效率，更好的跟蹤 客戶 和訂單的情況

不同於 ： OA管理系統

它的優勢是 ：結合業務的實際運行情況，基於訂製化的管理系統，提升效率

1. 需求描述

​ 銷售人員 登錄APP，如果沒有帳號則註冊帳號，登錄成功後，可以在系統上錄入客戶的基本資訊，根據客戶的房屋資訊創建項目，一個客戶可以創建一個或者多個項目，銷售人員根據客戶的意向情況，創建訂單，收取意向金，收取的意向金需要財務進行確認，並記錄審核的情況, 財務確認後，訂單專員可以看到訂單列表，審核訂單資訊，審核未通過，則通知銷售人員原因

​ 訂單專員可以給訂單綁定合約，如果該客戶下沒有合約，可以為客戶創建合約，並綁定，有合約，就直接綁定合約號，綁定的合約號會流轉到下游的系統中，訂單專員可以填寫排期單資訊，確定訂單沒有問題後，可以做訂單下達 ，當訂單的生命周期完結後，訂單專員可以完成訂單 ，訂單中途出現意外情況 ，可以作廢訂單

訂單狀態機：

1. 訂單已創建 ——> 訂單創建的初始狀態
2. 訂單已生成合約號 ——> 訂單綁定合約號成功
3. 訂單已下達 ——> 訂單下達成功
4. 訂單已完成 ——> 訂單完成了
5. 訂單已廢棄 ——> 比如客戶不想在公司做了 等情況 或者 沒有用的訂單不用跟蹤了，廢棄訂單

2. 規則

1. 意向金：向客戶收取的定金 ，可以任意的填寫 ，至少收取1千以上
2. 財務審核確認，線上支付的不需要財務確認，現金需要財務進行確認
3. 合約號生成規則：Gr + 年月日時分秒
4. 合約號必須綁定 ，不綁定不能做訂單下達
5. 排期單必須填寫，不填寫不能做點單下達
6. 用戶名必須唯一，必須填寫電話號碼 和郵箱，並驗證 ，密碼長度不能低於6位

3. 術語

1. 項目：在家裝行業，項目的基本資訊，一般就是客戶的房屋資訊，把房屋資訊當作項目資訊來管理
2. 合約號：合約的標識
3. 下游系統，另外一個服務或者第三方的系統

4. 干係人

1. 銷售 ，客戶 ，訂單專員 ，財務人員

   

2. 分析

   1. 銷售是支援者，錄入和收集客戶的基本資訊應該要盡量完善，這樣有利於設計師的設計和報價，面向的是客戶，挖掘更多的客戶資訊，有利於簽單
   2. 需要對客戶進行分層，不同的客戶，盡量匹配比較適合的設計師和銷售
   3. 財務人員審核的周期控制等
   4. 訂單專員審核的步驟可能很繁瑣，需要考慮他的痛點以及效率

5. 流程圖

6. 領域分析模型

參考資料

感謝各位老師的輸出整理

1. 公眾號：作者：少個分號，公眾號名稱：DDD和微服務， //mp.weixin.qq.com/s/3Ef7jzetIb7r_abH-i4Z8g
2. 51CTO 課程 ，領域驅動設計課程 —> 事件風暴
3. 解構領域驅動設計 —> 事件風暴