我们正在考虑在工作中实现 CQRS 模式，并且有几个关于验证的问题。
假设我们有 3 个聚合根:
用户业务UserToBusinessRelationship
当用户注册时发送的事件将是:
UserCreated
BusinessCreated
UserAddedToBusiness
事件需要经过验证，例如，要在用户和企业之间创建链接，用户和企业都应该被创建。
我看到了两种方法。
前期验证:使用上次处理的快照和未处理的事件动态构建读取模型，并将其用于验证。
处理时验证:按原样接受事件/命令并在处理事件时进行验证。
第一种方法有即时反馈，但它需要创建一个最终的读取模型来进行验证。第二个更简单，但不会向消费者提供出现问题的反馈。
我在想这样的事情:当你发出一个事件时，你会得到一个 id，你以后可以用它来查询事件的状态。如果事件处理成功，您会得到“OK”，否则您会收到错误信息，告诉您出了什么问题。
这是一种有效的方法还是矫枉过正？消费者如何知道事件已处理并且数据已准备好使用？
最佳答案
问得好 Leonti - 您可能会发现我关于在 CQRS 系统中进行验证的博文很有帮助。你可以在这里找到:How To Validate Commands in a CQRS Application .
只要从标题中注意到，CQRS 的重点是验证命令而不是事件。
为什么？
因为命令可能来自用户输入，因此不应被信任。 另一方面，事件是从域内发出的并且可以被信任。可能存在 CQRS 的实现，其中涉及离开系统边界的事件或接收并非源自系统内部的事件。在这些边缘情况下，应该小心。
另一个潜在的危险信号是您描述聚合的方式。在我看来(我不知道你的域，所以不能 100% 确定)它们更类似于数据库中的表而不是聚合。重要的是不要让你的持久化机制支配你的模型。
更具体地回到您的问题。
从广义上讲，有两种类型的验证。浅而深。肤浅的是缺少字段、有效的电子邮件地址等。深度是领域概念发挥作用的时候。例如需要 cargo 的重量和表面验证，但 cargo 是否适合承运人可能是一个领域概念。
您可能需要验证事物的存在。例如是否存在企业或用户。虽然这种验证很可能需要您访问数据库，但它仍然是肤浅的，因为它不太可能是一个明确的领域概念。
无论如何，我希望对您有所帮助。
关于domain-driven-design - 事件验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44694647/