验证CQRS中与其他域相关的命令

Question

我正在学习使用DDD、CQRS和ES开发微服务。这是HTTP RESTful服务。微服务是关于在线商店的。有几个域，如产品、订单、供应商、客户等。域内置在单独的服务中。如果命令有效负载与其他域相关，如何进行验证？

例如，这里是订单服务（命令端）中的addOrderItemCommand负载。

{
"customerId": "CUST111", 
"productId": "SKU222",
"orderId":"SO333"
}

如何验证上面的命令？如何知道客户真的存在于数据库中（查询端客服）并且仍然活跃？如何知道产品存在于数据库中并且产品的状态已发布？如何知道客户是否有资格从相关产品中获得促销价格？

直接调用API（如点对点/ajax/请求promise）来验证此有效负载以便命令端服务可以吗？但我认为，如果API只是为了验证而直接调用，那么性能会变得更差。因为，我们在命令服务之外开发了一个事件处理器，可以从事件中进行侦听，并将事件应用到物质化视图。

非常感谢。

Answer 1

与往常一样，一切都取决于域的具体情况，但作为一般原则，跨域验证应该通过读取模型完成。

在这种情况下，我将在每个微服务中维护一个读取模型，以用于验证。当然，这带来了最终一致性的问题。你如何处理这个问题应该取决于你对这个领域的理解。应考虑与更新频率相比的最终一致性长度等因素。与最小化问题的开发成本相比，业务出错的成本。在许多情况下，仅仅记录出现问题的事实就足够了。

我有一篇专门讨论验证的博客文章，您可以在这里找到：如何在CQRS应用程序中验证命令

Answer 2

由于需要查询多个有界上下文才能通过验证，因此需要考虑最终的一致性。这就是说，总有一种可能性，即整个过程可能在“一小”段时间内处于无效状态。例如，可以在接受命令后和订单发货前停用用户。网店是一个复杂的系统，任何子系统都可能出现异常。然而，作为一个事件驱动系统来实现是有帮助的；每次订购过程进入无效状态时，您都可以采取补偿措施/命令。例如，如果用户同时被停用，您可以取消其所有长期订单，释放保留的产品，宣布在愿望列表中有这些产品的潜在客户不可用等等。

DDD中有多种验证，但我遵循的一般规则是，应尽早进行验证，但不影响数据的一致性。因此，为了提前到达，您可以查询readmodel以拒绝不可能有效的命令，并且为了使系统保持一致，您需要在订单发货之前再次进行检查。

现在让我们谈谈你的具体问题：

如何知道客户真的存在于数据库（查询端客服）中并且仍然活跃？

您可以查询readmodel，以验证用户是否存在，以及该用户是否仍处于活动状态。您应该这样做，因为来自无效用户的命令是某种攻击的强烈迹象，您不希望此类命令通过您的系统。然而，即使命令通过了此检查，也不一定意味着订单将被发货，因为在这期间可能会引发其他异常。

如何知道产品存在于数据库中，以及产品的状态已发布？

同样，您可以查询readmodel，以通知用户该产品目前不可用。或者，根据您的业务，如果您知道根据之前的一些统计数据，这些产品将在24小时内可用（例如，您知道电视机每天都会进货），则可以允许该命令通过。或者，您可以让客户选择是否等待。在这种情况下，如果产品在订购（发货）的最后阶段没有库存，您会通知客户产品不再有库存。

如何知道客户是否有资格获得相关产品的促销价格？

您可能需要查询另一个有边界的上下文，如来检查这一点。这取决于促销的验证/使用方式。

为了命令端服务，直接调用API（如点对点/ajax/请求promise）来验证这个有效负载可以吗？但我认为，如果直接调用API只是为了验证，性能会变得更糟。

这取决于您希望系统的弹性以及拒绝无效命令的速度。

同步调用更容易实现，但它们会导致系统弹性较低（您应该注意级联故障并使用断路器等技术来阻止它们）。

异步（即使用事件）调用更难实现，但使您的系统更具弹性。为了进行异步调用，订购系统可以订阅其他系统的事件，并保持一个私有状态，当命令到达时可以查询用于验证目的。这样，即使库存或客户管理系统的链接关闭，订购系统也可以继续工作。

无论如何，这真的取决于你的生意，我们谁也不能确切地告诉你该做什么。