CQRS讀取模型側 - 規格化表

我一直在閱讀有關命令查詢責任分離（CQRS）以及這種模式如何適合我們當前的應用程序。CQRS讀取模型側 - 規格化表

當談到讀取模型時，我非常清楚以下概念：「分離讀寫數據模型」，「薄讀取層返回的平坦非規格化數據」。在大多數情況下，我們堅持使用相同的數據庫（相同的讀/寫數據模型），在具有規範化表的SQL Server上運行，並在其上使用公共分層應用程序。

那麼，在這種情況下應用CQRS有什麼價值嗎？如果是這樣，讀取模型端時會是什麼？

另一個令我想到的問題是MVC應用程序從我的瘦讀取層請求信息，這些信息暴露了平坦的視圖。暴露的數據在呈現給用戶之前仍然需要進行結構化（集成），還是我錯了？

問候

來源

2013-04-03 Dzenan

CQRS不需要有一個扁平的讀取模型;這是CQRS允許您提供的好處，但它既不是必需的也不是該方法的關鍵部分。

CQRS是關於分離（或如果您按照名稱隔離）。這是類固醇的命令查詢分離原則（在我看來）。它爲您提供的好處（離開我的頭頂）是：

將讀取操作與寫入操作分開;
通過消息傳遞（例如命令，事件）層之間的通信，以便您的圖層乾淨;您層內
分離，應用單一職責原則（如您的域名應用的業務邏輯，你的命令處理route命令，您denormalizers或事件處理程序（或者無論你怎麼稱呼他們）堅持信息到您的閱讀商店等）
允許您讓團隊成員在應用程序的不同部分上工作，而不會在他們之間產生嚴重的依賴關係;
等

因此，如果上述這些東西給你，或者你要爭取（和應用程序的設計支持實施CQRS）一些重要的東西，然後CQRS提供的利益和價值給您。

CQRS有許多好處。這不是每個問題的正確解決方案，但是當星星對齊時，這對你的問題是一個很好的方法（即使你沒有非規範化的讀取存儲，事件存儲或異步模型等）。

我希望這有助於！

來源

2013-04-04 12:54:42

應用CQRS在相同的（比如說）第三範式的數據庫仍然可以給你讀出側的值，如果它允許你停止從域對象投射閱讀模式。

這也可以讓你更好地專注於你的域名（我假設）交易處理，這意味着許多關係可能不是必要的。

來源

2013-04-03 11:54:40

我多打加入了這麼多次在我的職業生涯，當像CQRS和ES結構走來，並提供一個清潔的方式來簡化讀取方面，我在它跳了下去。好的是，您可以獲得許多好處，而不必實現與CQRS和ES經常相關的所有元素。從查詢中分離命令有利於簡化代碼。但是，當您開始使用反規範工具爲您的應用程序構建讀取模型時，您會突然意識到應用程序的簡單性，清潔性和高性能。

如果有幫助，看看這個去規範化「如何」運作來看看這篇文章（它帶有一個代碼示例採取甘德在）：How to build a master details view with CQRS and ES。我希望你覺得這有幫助。

來源

2014-10-07 14:20:17 Codescribler

CQRS讀取模型側 - 規格化表

回答

相關問題