CQRS - 是否允許從寫入側調用讀取側？

是否允許在寫入端調用讀取端以獲取更多信息？

http://cqrs.nu/Faq/command-handlers這裏他們說這是不被允許的，但在cqrs旅程代碼中，我發現他們調用了一個內部使用DAO服務類的服務'IPricingService'。

那麼我需要做些什麼才能在我的聚合根目錄中獲得更多信息？

2015-07-10 Thomas Geulen

CQRS旅程不應被視爲手冊。這只是一些團隊與CQRS戰鬥的故事，並且僅限於使用Microsoft堆棧。本身你不應該在命令處理程序或域邏輯中使用你的讀取模型。但是您可以從客戶端查詢您的讀取模型以獲取您的命令所需的數據並驗證命令。

既然我對這個答案有了一些看法，我需要指出的是，我寫的是模式中的慣例。讀取側都不訪問寫入側，寫入側不從讀取側獲取數據。

然而，「客戶」的定義可能是討論的主題。例如，我不相信面向公衆的JS瀏覽器應用程序是一個合適的「客戶端」。相反，我會使用我的REST API層作爲CQRS中的「客戶端」，而Web應用程序將僅僅是此客戶端的UI層。在這種情況下，REST API服務調用處理將成爲合法的讀取方讀取器，因爲它需要驗證所有發送的UI層以防止僞造並驗證一些業務規則。當這項工作完成後，命令形成併發送到寫入端。驗證和其他一切都是同步的，然後命令處理是異步的。

更新：根據下面的一些分歧，我想指向Udi's article from 2009談論一般的CQRS，特別是命令和驗證。

來源

2015-07-10 11:02:02

我不同意。如果你需要你的命令包含處理程序需要驗證你的命令的數據，那麼你永遠不會改變你的處理程序/域中的驗證邏輯，而不會影響* client *。這清楚地向客戶公開了太多的命令驗證/領域知識，並且與客戶僅僅想表達意圖相矛盾。恕我直言，更好的解決方案是向您的聚合根提供一個'PricingService'接口（這是無處不在的語言的一部分），然後根據需要實現接口 - 這可能包括查詢讀取方。 –

我將不得不繼續這一個。 – JoG

@AlexanderLanger這不是我發明的東西，這是模式的設計。你可能會發現可以從你的命令處理程序中查詢讀取的一面，但這不是所討論的模式。如果您查看CQRS上的任何圖表，您將永遠看不到讀取模型是由寫入模式查詢的。它只能由客戶讀取。 –

的CQRS FAQ（http://cqrs.nu/Faq）指出：

「我怎樣才能限界上下文之間的溝通

獨家在其公共API而言，這可能涉及訂閱從另一個界上下文未來事件或？。一個有界的上下文可以像另一個常規客戶那樣行事，發送命令和查詢。「

因此，儘管在一個BC內，不可能在寫入端使用讀取端，反之亦然，但另一個有界的上下文或服務可以。實質上，這將會像使用用戶界面的人一樣行事。

來源

2017-04-11 17:12:49

CQRS - 是否允許從寫入側調用讀取側？

回答

相關問題