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

事件建模過程
要遵循事件建模過程，需要採取以下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投射：將事件流轉換為狀態。