如何實現DDD事件建模的詳細步驟 - goeleven

為了分析現有的業務流程，我使用了一種稱為事件建模的技術。這種建模技術主要集中於識別在業務流程中發生的有意義的業務事件。一旦識別出這些事件，它們便構成了設計過程的基礎，該設計過程導致了DDD，CQRS和ES中描述的一組處理模式得以實現。

事件建模是亞當·迪米特魯克（Adam Dymitruk）創造的一個術語，但該技術本身是建立在其他人的工作基礎上的，例如埃裡克·埃文斯（DD），馬丁·福勒（Eventsourcing），格雷格·揚（CQRS）和阿爾貝託·勃蘭多利諾（事件風暴）。

總的來說，這些模式的實現可以以數字方式支援所分析的業務流程。

如果您想將建模工作作為研討會來進行，可以將Event Storming納入其中，但也可以自己完成。

事件建模過程

要遵循事件建模過程，需要採取以下7個步驟：

1. 識別事件
2. 建立時間線
3. 故事板
4. 識別使用者輸入和命令
5. 識別使用者所需的資訊
6. 將事件分組為自治元件
7. 識別訊息處理模式

步驟1：找出事件

第一步，我將確定在執行現有業務流程期間發生的對業務有意義的事件。

例如，我將使用體育俱樂部的籌款流程的簡化版本（預定之類的電子商務網站）。

它包含以下事件：

• SalesOrderBooked
• SalesOrderCommented
• OrderConfirmationRequested
• DiscountGranted
• PaymentReceived
• SalesOrderValidated
• ProcessingStarted
• DeliveryConfirmed

我將它們記錄在橙色的便籤紙上，然後將它們放在設計圖面上。

“對業務有意義”意味著事件是狀態變化的結果，狀態變化使業務流程向前發展。因此SalesOrderBooked被認為是有意義的，SalesOrderValidated可能沒有意義，因為它不會進一步推動該過程。

通常，識別過程中最重要的事件很簡單，但是識別哪些是有意義的，哪些才是正當的，將需要一些時間和思想。

沒關係，因為無論如何我都會迭代處理功能，因此在獲得新的見解時，我可以在以後的迭代中新增，修改和刪除事件。

步驟2：建立時間表

接下來，我按時間順序組織已識別的事件，以便它們共同構成一個連貫的故事。

這樣做時，我可能會發現缺少的事件，應將其新增到時間軸中。

我甚至可能會發現太多丟失的事件，以至於可以將它們自己分解為一個新的業務流程。

同樣，我可能會發現，某些先前確定的事件實際上屬於不同的過程，或者屬於所分析過程的不同變體。

無論在哪種情況下，我都將這些事件擱置一旁，並在另一天進行處理。我一次只講一個故事。

對於其他故事，只需重複該過程即可。

步驟3：情節提要

既然已經按照正確的順序定義了事件，那麼我將開始考慮參與該過程的不同人員的使用者體驗。

當故事中有多個角色時，我會為參加活動的每種型別的人使用泳道。

在此示例中，有一個Funder定購食品，一個Fundraising Manager用於跟進訂單並處理物流，還有Checkin clerck一個將在募款日確認訂單，處理並交付訂單的食品。

對於這些角色中的每一個，我將繪製線框或模型以視覺化角色如何參與該過程。

我必須決定哪種視覺方式將以最佳方式傳達資訊：列表，日曆，導航搜尋或其他？

如果使用者需要使用表格來輸入資訊，則需要確定需要按下的按鈕，表格上的哪些欄位用於資料收集等，等等。

步驟4：識別使用者輸入和命令

每種輸入形式或按鈕都應導致一個或多個命令，這些命令將被髮送到系統進行處理。

我將在圖形和命令處理之間在輸入表單和事件之間新增一個命令，通常以藍色便籤紙的形式。

例如，當Funder某人想要預訂籌款活動時，她可以從俱樂部網站發出Book命令，這將導致SalesOrderBooked系統內部發生事件。

我還將花一些時間來定義應在命令上顯示的資訊，以使系統能夠在該命令上執行該資訊。通常，我會將其記錄為與便利貼相關的評論。

- OrderId: generated
- Buyer 
    - Name: form field
    - Email: form field
- OrderLines
    - Id: generated
    - Quantity: form field
    - OrderedItem
        - Id: ?
        - Name: ?
        - Price: ?

這樣，我可以驗證使用者所需的所有資訊都以資料輸入欄位形式或以可視資訊形式存在於模型中。

如果缺少某些資訊，則這可能是一個很好的指示，說明我缺少定義它的另一個業務流程。

步驟5：識別使用者所需的資訊

使用者將需要在其螢幕上提供資訊，以便做出明智的決定並呼叫正確的命令。

然而，人類並不擅長將大量事件消化成有意義的東西。因此，系統需要建立這些事件中包含的資訊的摘要。

在我的分類法中，這些摘要稱為狀態，由綠色便籤紙表示。有時需要採取行動將狀態告知使用者，例如通過向他們傳送電子郵件。在這種情況下，我將使用粉紅色的便籤紙。

例如，當一個Fundraising Manager想給予訂單折扣時，系統將不得不向她提供一個Orders可供選擇的清單。這是在此步驟中需要識別的資訊。

我將所有必需的狀態新增到圖形中，並定義物件的形狀，以及需要顯示的資訊。如果狀態很簡單，我將其新增為連線到便利貼的註釋，否則，我可能會在側面繪製一個小的UML圖。

然後，將狀態連線到儲存資訊的事件，以便填充資訊。

步驟6：將事件分組為自治元件

一旦瞭解了流程中不同人員之間的資料流向後，就必須決定資料在系統內部的流向。

可以通過將事件分組到泳道中來定義元件，以使每個泳道都具有最大的自治權，並且每個泳道可以由一個單獨的團隊擁有。

以下步驟是自治的，它們在不同的時間，不同的位置，由不同的人員執行：

• OrderBooking：此步驟是預先執行，以紙質形式或通過俱樂部網站執行的。所有資訊都需要最終到達籌款經理處以計劃籌款活動。
• Payment：資金由司庫分開處理，以現金，電匯或線上交易的方式接受。
• OrderProcessing：此步驟僅在募捐活動當天由一組志願者執行。

避免按名詞分組（這是一個非常常見的錯誤），請確保按自治分組，並且各元件之間的依存關係應儘可能小。

另外，請確保不違反康威定理，並考慮到您的組織結構，以便每個自治元件也可以在組織內部得到自主支援。

步驟7：確定訊息處理模式

現在，從產生的事件模型中，我可以確定訊息流中存在的訊息處理模式。對於每種模式，都有一種在俱樂部管理系統中實現它們的標準化方法。

有多種處理模式可在任何方向上在命令，事件和狀態之間轉換，在上面的圖中，我已經顯示了一些處理模式。

• Aggregate Root聚合根：根據命令做出業務決策，並將其記錄為事件。
• Event Stream Processing：將事件流轉換為其他事件。
• Downstream Activity：基於命令或事件呼叫動作。
• Projection投射：將事件流轉換為狀態。

總共有9種模式可支援命令，事件和狀態之間的轉換。

通過實施這種有限的模式集，您可以支援現有的大多數（如果不是全部）業務流程。