在DDD中讀取聚集的模型CQRS ES

Question

在CQRS + ES和DDD中，聚合的小型讀取模型從其他集合或有界的上下文中獲取數據是否是好事？

例如，在訂單驗證（按訂單彙總）中，有一個業務規則僅在客戶未被標記時驗證訂單。標誌信息通過同步域事件放入讀取模型（特定於聚合）。

您對此有何看法？

Answer 1

爲了從其他集合或有界的上下文中獲取數據，使用小型閱讀模型是一件好事嗎？

這並不理想。由於它們的性質，聚合不善於執行涉及自身以外的狀態的一致性。

這通常意味着當兩個聚合產生不可接受的狀態時，企業將需要某種方式進行響應。

您還可以在聚合上運行placeOrder命令之前檢查該標誌。該檢查標誌可以在命令處理程序或客戶端中完成 - 基本上，您已經「驗證」該命令在傳遞到聚合之前應該成功。這就是說，如果在處理命令時試圖諮詢讀取模型非常關鍵，那麼一種方法是使用「域服務」。您將服務提供者作爲命令的一部分傳遞給聚合，並讓接口抽象出運行查詢需要查看聚合之外的事實。

這給你一些你需要保持聚合測試的解耦。

Answer 2

這是可行的，但不是讀取模型的形式，而是聚合中的值對象（因爲我們在寫入方面）。

如果您已在Order中有CustomerId，您只需編寫一個VO和它以及一個Flagged成員。

當然，由於數據來源於Customer，所以仍然存在交叉聚合通信的所有問題。 Order必須與其客戶的標記狀態保持同步，這可能需要相當多的工作。

無論如何，您應該首先確定您的領域專家是否立即一致性是絕對要求（在這種情況下，您必須以某種方式在交易中包裝客戶+訂單），或者您可以承受標記的小延遲執行該不變量時新鮮度。 如果是後者，您可以選擇在Order聚合中重複標記或由@VoiceOfUnreason給出的第一個選項 - 主要的區別可能在於，如果數據是聚合的，您可以在域級別免費獲得它您需要多次使用它，而不是在應用程序級別的多個用例/命令處理程序中複製檢查。