CQRS如何爲更多可擴展的應用程序做出貢獻

最近我在CQRS架構上閱讀了很多。關於爲什麼應該使用CQRS的一個最重要的觀點是可擴展性。CQRS如何爲更多可擴展的應用程序做出貢獻

現在我不太明白這是如何工作的。

比方說，你有你的typical CQRS應用程序設計。

兩個數據存儲
一個用於指揮邊
一個用於查詢側面
當命令已處理的事件是發送可能更新第二數據存儲

這往往表示擁有一個用於查詢的數據存儲和一個用於處理命令的數據存儲會使您的應用程序更具可擴展性。但是，如果存儲事件數據的第二個數據存儲庫需要響應查詢請求並且不斷需要基於傳入事件更新iteself，那麼這將如何工作？

爲什麼不在一個數據存儲中存儲命令，以及查詢端可以重新使用存儲的數據來獲取結果數據？

來源

2014-06-10 Jonas Geiregat

你可能會覺得自己有興趣從Greg Young自己讀這個old blog post，他在那裏解釋了CQRS究竟是什麼。

CQRS是不是有2家不同的商店，但是，對格雷格的文章爲表示：

CQRS簡直就是在那裏以前有只有一兩個對象的創建。分離根據方法是命令還是查詢

這裏描述的是更多事件採購。

現在回到你的問題：How can CQRS contribute to more scalable applications? 格雷格回答說還有：

CQRS允許以不同的方式如舉辦兩項服務：我們可以把主機上的25臺服務器的讀服務，在兩個寫服務。命令和查詢的處理基本上是不對稱的，並且對稱地縮放服務並不很有意義。

就是這樣！

來源

2014-06-10 08:13:40 MaxSC

Two Datastores 
One for the Command Side 
One for Query Side 
When a Command has been processed an Event is send which could update the second Datastore

這是CQRS與ES（事件採購），不要混淆的東西！

事件源是關於存儲處理傳入命令引發的域事件。所以你可以隨時播放他們。這使得讀取方更加靈活，因爲您可以隨時更改讀取的數據庫結構，之後您只重播域事件而不是編寫一些特殊的遷移代碼。存儲命令並不好，因爲你不一定具有相同的環境（例如服務器上的不同時間），所以你不能安全地重放它們。命令存儲僅用於日誌記錄目的...

命令和查詢職責隔離是關於將傳入請求分成兩組：寫入（命令）和讀取（查詢）。這背後的基本思想是，通過編寫您使用的關係數據庫，您不必使用相同的ORM實體。所以你可以通過讀操作省去對象 - 關係映射，這使得事情變得更快。後來它經歷了一次改進，現在這意味着您可以通過讀取部分使用多個數據庫，每個數據庫都針對一組查詢。例如，如果像neo4j這樣的圖形數據庫適合某些查詢，那麼您將添加一個neo4j數據庫，而不是使用相同的關係數據庫來提供這些查詢。這可以使事情變得更快......

來源

2014-06-10 08:56:58 inf3rno

如果像neo4j這樣的圖形數據庫適合某些查詢，那麼您將添加一個neo4j數據庫，而不是使用相同的關係數據庫來提供這些查詢。這可以讓事情變得更快... ... ** Greg Young說：「錯誤的模型導致了巨大的意外複雜性」 – MaxSC

ES不是關於存儲事件。這是關於通過應用事件來改變對象狀態的。而CQRS在沒有ES的情況下效果很好。 – MikeSW

@MikeSW「ES不是關於存儲事件，而是通過應用事件來改變對象狀態。」 - 其實你錯了，我的意思是事件採購是一種存儲機制，它和我們用不同的詞語描述的方式一樣。「而CQRS在沒有ES的情況下效果很好。」 - 沒有人說別的。 – inf3rno

CQRS如何爲更多可擴展的應用程序做出貢獻

回答

相關問題