如果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思维模式的问题。
你可能想退后一步，问为什么在发送命令之前知道计数器值是绝对必要的？显然，你想在客户端做出决定，你是否可以增加计数器。
该方法是让服务器做出这样的决定。让所有的客户端发送命令（有些会成功，有些会失败）。 最终客户端将获得服务器对象状态（已达到限制）的一致视图，并可能最终停止发送此类命令。
这个时间窗口的不一致导致客户端做出错误的决定，但只要命令得到充分处理，它就不会破坏服务器端对象（或域模型）的一致性。