事件采购和验证上写

Question

还是蛮年轻的ES和CQRS，据我所知，他们密切相关的数据的最终一致性。

当我们在写入商店之前应该进行验证，比如检查电子邮件地址是否已经被现有用户使用，最终一致性可能会有问题。以一致的方式做到这一点的唯一方法是停止接受新事件，根据我们的观点完成剩余事件的处理，然后查询视图。我们显然不想走得那么远，Greg Young实际上是recommends，以接受最终的一致性并处理（罕见的）我们违反约束的情况。

推动这种方法达到极限，我的理解是，这意味着，例如，在开发Web API时，对每个请求做出“OK”响应，因为在请求时不可能验证它...我在正确的轨道上，还是在这里错过了什么？

Answer 1

正如我在上面的评论暗示，a RESTful API can return 202 Accepted。

这提供了一种客户端轮询状态更新的方法，如果这是必要的。

客户可以监视器的状态，如果这是可取的，但或者，它也可以简单地消防和忘记，假设如果它得到任何排序200 -range响应，该命令将最终应用。如果您有可以传播错误的替代渠道，这可能是一个很好的选择。例如，如果您知道哪个用户提交了该命令，并且拥有该用户的电子邮件地址，则可以在应用该命令失败的情况下发送电子邮件。

CQRS体系结构的要点之一是系统的边缘在接受它之前应该尽其所能来验证命令的正确性。基于系统的已知状态（由查询方暴露），系统可以做出强烈的努力来验证给定命令是否可接受。如果这样做，那么如果接受Command，则唯一的永久性错误是并发冲突。根据系统接近一致状态的速度，这种并发冲突可能很少，例如，向用户发送电子邮件是一种适当的错误处理策略。