CQRS和命令，CommandHandler和聚合验证

Question

我正在新项目中实施CQRS的第一步。 遵循CQRS方法，我将MediatR用作协调命令的框架。

我还使用FluentValidation和ValidationBehavior来实现命令验证。 但是我在努力定义将哪种验证放在哪里：

• 在命令中（将CommandValidator与FluentValidation结合使用）
• 在命令处理程序中，作为自定义检查
• 在聚合根目录中（直接在此聚合上调用操作时）

我想了解将验证放在哪里：

• 字段验证（长度，格式，必填...）
• 要求实现IRepository的业务规则验证（例如，基于列而不是基于主键的唯一性）
• 不需要实现IRepository的业务规则验证

由于我目前已经实现了它，所以我无法在聚合根目录中访问IRepository实现。 是由DI注入此存储库的命令处理程序，它们在聚合根上执行操作，但还负责调用例如Save或Add以最终更新数据库。

Answer 1

在“理想的” CQRS中，您的聚合状态应包含执行命令所需的所有内容，并且您不应在命令执行期间与其他聚合对话（因为它们超出了一致性范围）

因此，业务规则验证（决定是否可以执行给定命令）应转到聚合的命令处理程序中。

在客户端上发送命令之前，以及在将命令传递给命令处理程序之前（由于我们无法完全信任客户端），应检查命令格式设置规则（必填字段，允许的值）。

因此，我会将命令格式验证规则保留在更接近命令定义的位置-可能以声明性形式出现，而不是作为专用的验证器。

在某些情况下，如果不查询其他聚合的状态，聚合将无法完全检查命令的正确性。 这是有关聚合间通信的好文章 。 简而言之-您不应在命令执行过程中与其他聚合对话。

经典示例是使用唯一名称创建用户。 社区共识似乎是：

• 您可以在发送命令之前验证用户名在客户端中是否唯一。

• 用户聚合执行命令时不检查唯一性。

• 在发送命令之前有人注册了相同用户名的极少数情况会陷入投影代码中，并导致手动解决异常。 还是有些传奇人物会监视重复的用户名并以某种方式处理此问题。

因此-需要更好地进行跨集合通信的业务规则验证应放在Saga / Process Manager中