如果CQS阻止命令返回狀態變量，那麼對於可能不會成功的命令的代碼如何？假設你不能依靠例外。命令查詢分隔：命令必須返回無效？
似乎任何請求/響應都是對CQS的違反。
所以看起來你會有一套「母親可能」的方法給出的命令將返回的狀態。多線程/多計算機應用程序中會發生什麼？
如果我有三個客戶端請求服務器的對象增加1（並且對象的限制爲0-100）。所有的檢查，看看他們是否可以但只有一個得到它 - 而其他兩個不能，因爲它剛剛達到極限。這似乎是一個返回的狀態將在這裏解決問題。
似乎任何請求/響應都是對CQS的違反。
差不多肯定的，因此命令查詢 - 分離。正如馬丁·福勒nicely puts it：
的基本想法是，我們要分對象的方法分爲兩個明顯劃分類別：
查詢：返回一個結果，不改變系統的觀測狀態（沒有副作用）。
命令：更改系統的狀態，但不返回值 [我的重點。
請求由一個服務器的對象增加一個命令，因此它不應該返回一個值 - 處理該請求的響應意味着你正在做的，在打破了同時命令和查詢行爲CQS的基本原則。
所以，如果你想知道服務器的價值是什麼，你發出一個單獨的查詢。
如果你真的需要一個請求 - 響應模式，您可能需要有一些像一個錯綜複雜的回調事件過程中發出查詢特定請求的狀態，或純 CQS是不恰當的，這部分你的系統 - 注意單詞純。
多線程是CQS的一個主要缺點，可以使它很難做到。 Wikipedia對此有着基本的例子和討論，還可以鏈接到他表明，它是確定以打破這種模式得到的東西沒有自己開車瘋狂做同樣的Martin Fowler的文章：
[貝特朗]邁耶[發明者CQS]喜歡使用命令 - 查詢分離，但有 例外。彈出堆棧是修改 狀態的查詢的一個很好的示例。邁爾正確地說，你可以避免使用這種方法，但它是一個有用的習慣用法。所以我更喜歡遵循這個原則，當我可以， ，但我準備打破它，讓我的流行。
TL; DR - 我可能會只看返回響應，即使壽這是不正確的CQS。
文章"Race Conditions Don’t Exist"可能會幫助您查看CQS/CQRS思維模式的問題。
你可能想退後一步，問爲什麼在發送命令之前知道計數器值是絕對必要的？顯然，你想在客戶端做出決定，你是否可以增加計數器。
該方法是讓服務器做出這樣的決定。讓所有的客戶端發送命令（有些會成功，有些會失敗）。 最終客戶端將獲得服務器對象狀態（已達到限制）的一致視圖，並可能最終停止發送此類命令。
這個時間窗口的不一致導致客戶端做出錯誤的決定，但只要命令得到充分處理，它就不會破壞服務器端對象（或域模型）的一致性。