在正確設計的應用程序中，可能會將所有請求分開（僅更新聚合並返回void）和查詢（從特定的讀取優化模型中提取數據）。如何使用CQRS處理MixedQuery？
但是，如果您已經有一個沉重的應用程序，並且想要慢慢將其移至ES + CQRS路徑，則可能會請求修改和更新模型並返回所有結果（如果執行了命令然後查詢但這將是2請求）這就是我的意思是混合查詢。
我明白，這顯然是teoretical的問題，我沒有這裏的任何代碼來說明，但
你如何處理與CQRS這樣的要求？
看來你基本上是在談論犧牲Command-Query Separation，這是CQRS的一個先決條件，也是一個很好的開發實踐。
如果我要轉移到CQRS方法，我會開始通過符合CQS（如果有的話），在引入整個CQRS設備之前，從方法級別分離命令。
您不必將它作爲大爆炸重做，您可以通過功能切片進行功能切片，確保您具有高級自動化測試以確保重構。
您的「混合查詢」超出了CQRS的範圍。我的答案是 - 如果你有這個，你沒有CQRS。 CQRS的意思是命令和查詢是分離，這是整個點。
您不必立即將所有內容移動到新模型，您將有兩個平行系統並逐個移動到另一個。我強烈建議不要將舊東西混合到新模型中。
例如從希望創建一個新用戶的應用程序的簡單請求，它至少應得到一些想法，如果整個事情了OK或者失敗... 什麼是做CQRS這種行爲的正確方法？我認爲這是一個很常見的例子... – vach
我可以想到的解決方案，如果你有一個像websocket客戶端全雙工通信然後更新後讀取模型它可以發送更新給用戶，但我不認爲這是大多數情況下應用程序... – vach
該命令可能會因異常而失敗，如果您的命令已完成，這將是一個很好的指示。在CQS命令中不返回任何東西，即狀態變異方法總是無效的。當你的命令返回實際的聚合時，可以建立流暢的接口，這也可以。但CQRS「將一個對象拆分爲兩個」，因此寫入模型不應該從讀取模型中查詢任何內容，並且肯定不應該返回任何查詢結果。 –
這比CQRS更接近CQRS嗎？ – guillaume31
它不是，但我做的是devide成小項目，小的獨立模塊和現在我想重構/與CQRS重新設計了相當多的事情要做。但是現在我在理解它是否能夠在實際遷移之前處理我想要使用它的一些問題。 – vach