EventSourcing內部和外部有界的上下文

Question

我試圖用dddd實現事件源系統。目前我正在掙扎着我的事件如何以及在哪裏跨越有界的環境邊界。

想有兩個限定語境：

1. 產品管理
2. 物流系統

產品管理擁有所有有關產品的知識。爲了簡化，它只是「名稱」。物流系統也有產品，但不瞭解他們的元數據。對他們來說，它大多隻是一個帶有Id的物理盒子。但是當有人掃描這個產品時，他們也想顯示這個名字。因此，產品管理委員會應通知物流BC，產品已註冊且名稱已更改。因此，我將結束在產品經理的事件，從ProductAggregate裏面提出：

ProductManagement.Events.ProductRegistered 
ProductManagement.Events.ProductNameChanged 

當我得到了它正確這些是我將保存到事件存儲的事件。這些也是將要發佈到消息總線上的事件。所以在後勤方面我會訂閱這些活動。到現在爲止還挺好。

現在的問題是： 我將如何在物流方面處理此事件？ Vaughn Vernon在一次演講中表示，最好有一個事件處理程序，它位於應用程序層中，因此它基本上是一個應用程序服務。他還表示，最好將其轉換爲一個或多個命令。我是否將所有收到的事件再次保存在物流方面？我是否也保存這些命令？如果出現問題，我該如何重現當前狀態？或者我怎麼知道，它不是接收有界上下文中的處理過程的錯誤，而是錯誤的事件。如果我的轉換命令被拒絕，我該怎麼辦？

我知道在物流方面沒有計算或總量變化。但我認爲這對我的問題無關緊要。

Answer 1

這裏有些東西。

首先，您不必導入關於名稱更改的物流BC。您可以在客戶需要時從PM BC獲取此信息。這通常由某種合成UI完成。 UI組成可以在客戶端或（網絡）服務器上完成。你可能想看看Mauro Servienti的文章The secret of better UI composition，描述這個。

但在一般情況下，這通常是這樣的：

domain event -> pub/sub -> message consumer -> command -> domain command handler

所以，

1. 您發佈域事件到總線，從PM BC
2. 存在此事件的事件處理程序在物流
3. 事件處理程序可能會執行一些檢查，併發送RegisterProduct命令相同的BC
4. 的命令像往常一樣處理，並在物流

它是這樣工作不僅在事件源系統，但在具有多個服務的任何系統，利用事件創建新Product彙總驅動架構。

Answer 2

對於您描述的用例，您只需要物流系統使用的產品的某些屬性。因此，物流系統可以通過訂閱您描述的事件來保留它所需的產品信息的本地緩存 - 這可能是一個簡單的內存緩存。在處理讀取模型I.e時，他們不需要轉換成命令或類似的東西。一個看法。只需要一個簡單的事件處理程序來處理事件並在某處更新某個狀態 - 無需在讀取一側事件源。當物流系統需要產品名稱時，只需從本地緩存中獲取。由於產品管理仍然是事實的根源，您還沒有打破這兩種背景的自主權。

如果您需要重建狀態，您可以擦除緩存並通過處理程序重播所有事件。但請記住，產品管理上下文擁有這些事件，因此它們只應保存在那裏，而不是在後勤環境中 - 如果您想重新構建狀態，則需要重新發布它們的方式

順便說一下，本系列博客文章描述這個確切的使用情況：

https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-1/

（在第5部分，如果我沒有記錯）

或者你可以做一些UI組成的，其中名稱是從產品管理上下文和其他採取來自物流環境的細節（也包括光盤在上述博客文章ussed）

Answer 3

[...]他還表示，這將是最好把它轉換爲一個或多個命令。我是否將所有收到的事件再次保存在物流方面？我是否也保存這些命令？

首先，您必須詢問領域專家，看看該事件是否會導致影響LS上下文的副作用。只有在這種情況下，您必須訂閱此事件並將相關命令發送給將改變並提交其狀態的LS Aggregate，或者如果您選擇事件來源彙總此另一個事件。

如果出現問題，我該如何重現當前狀態？或者我怎麼知道，它不是接收有界上下文中的處理錯誤，而是錯誤的事件？如果我的轉換命令被拒絕，我該怎麼辦？

事件是發生事件的表示，所以它不能是「錯誤的」。無論如何，由事件觸發的命令可能會失敗。你在談論哪種類型的失敗？技術或領域特定？在第一種情況下，源事件將留在公交車上以備將來重試（可能是在修復了一些錯誤之後）。在第二種情況下，如果PM集合需要被告知結果，LS集合應該發出適當的事件，然後由PM集合來處理。