域驅動設計中的上下文之間的通信

Question

在我的公司，我們目前使用DDD體系結構，結合事件源和CQRS。在最初的版本中，我們允許每個上下文從任何其他上下文接收事件。然而，這很快就變成了一團糟，因爲很難跟蹤哪些事件在哪裏處理。

我們目前的方法是隻允許命令發送到其他上下文。這效果更好，但它似乎產生了很多代碼開銷。例如：

context A sends a command to context B, 
which changes the state of a domain model, 
which publishes an event, 
which gets handled by an event handler, 
which sends a command back to context A, 
which changes the state of a domain model, 
which publishes an event, 
which gets handled by an event handler, 
which sends a command to context C, 
etcetera. 

許多在不同的上下文的域模型的，和大量其觸發發送到另一個上下文中的命令的事件的，含有大量的類似的數據。特別是在我們的客戶網站上下文中，模型幾乎不包含任何邏輯或狀態，只是用於生成可以非規範化到網站數據庫的事件。它的工作原理，但這似乎還沒有走，因爲發佈事件不應該是任何領域模型的唯一目的。

我們現在的想法之一是讓我們的CMS像域模型一樣工作，並直接處理命令，而不是通過模型發送它們並處理結果事件。這是處理這類案件的正確方法嗎？還有其他更有效的方式來進行上下文之間的溝通嗎？

Answer 1

在初始版本中，我們允許每個上下文從任何其他上下文接收事件 。然而這很快就變成了一團糟，因爲它很難追蹤哪些事件在哪裏處理。

我沒有看到這個問題。 BC之間通過事件進行通信是典型的事件驅動架構。事件的跟蹤可以通過上下文映射來完成。

似乎在您的情況下，公元前互動變得過於瑣碎。這可能是次優邊界的症狀。也許邊界太粒度？鑑於幾個領域模型包含大量類似的數據可能表明這些領域應該合併。 BC的基本原則是功能和語言cohesion - 密切相關的東西粘在一起。

響應命令後發佈事件的域模型更改狀態是一個完全有效的工作流。

尤其是在我們的客戶網站方面，該機型包含幾乎 沒有邏輯或狀態，只是用於產生可 非規範化的網站數據庫事件。

這似乎像CQRS術語中的視圖/投影。再次，這裏沒有錯。

我們的一個想法，現在是使我們的CMS的行爲像一個域模型，並 手柄命令通過模型和 過程中所產生的事件，向他們發送的，而不是直接。

這可能是一個重要的觀察。完整的領域模型在業務邏輯複雜的情況下很有意義。但是，如果域名是CMS的域名或CRUD，則不需要域模型。但是，您仍然可以保留事件驅動架構的其餘部分。