ES和CQRS还很年轻，我知道它们与最终的数据一致性密切相关。
当我们在写入商店之前执行验证时，最终的一致性可能会有问题，例如检查电子邮件地址是否已被现有用户使用。以强烈一致的方式执行此操作的唯一方法是停止接受新事件，针对我们的视图完成剩余事件的处理，然后查询视图。我们显然不想走得那么远，Greg Young实际上recommends接受最终的一致性并处理我们打破限制的（罕见）案例。
将这种方法推向极限，我的理解是，这意味着，在开发Web API时，例如，回应“确定”。对于每一个请求，因为在请求时不可能对其进行验证......我是在正确的轨道上，还是在这里遗漏了什么？
答案 0 :(得分：2)
正如我在上面的评论中所暗示的，a RESTful API can return 202 Accepted。
如果有必要，这为客户提供了一种轮询状态更新的方法。
如果需要，客户端可以监视状态，但是，它也可以简单地触发并忘记，假设它是任何类{{1} } -range响应，命令将最终应用。如果您有可以传播错误的备用通道，这可能是一个不错的选择。例如，如果您知道哪个用户提交了该命令，并且您拥有该用户的电子邮件地址，则可以在未能应用该命令时发送电子邮件。
CQRS架构的一个要点是系统的边缘应尽其所能在接受命令之前验证命令的正确性。基于系统的已知状态（由查询方面公开），系统可以努力验证给定命令是否可接受。如果它这样做，那么接受命令时应该发生的唯一永久性错误是并发冲突。根据系统接近一致状态的速度，这种并发冲突可能很少，例如向用户发送电子邮件是一种适当的错误处理策略。