cqrs - 使用其他模型进行验证

Question

验证使用其他模型的事件的选项有哪些？

购物车示例：

将购物车项目添加到购物车时，应该检查该项目是否尚未售罄。

Answer 1

您通常会验证命令而不是事件，因为事件应该是无法更改的

在回答这个问题时，通常取决于流程的业务成本是多少。例如，在您的示例中，订购已售罄的商品的业务成本是多少？可能很少——一封电子邮件说该商品缺货，并估计需要多长时间。

在这种类型的场景中，您可以对数据使用最终一致的读取模型，您可以在其中查询读取模型/缓存的库存水平，但接受一些订单可能会处理缺货的事情。

如果您有更严格的约束，那么您将不得不强制执行它们，理想情况下是通过重塑您的聚合，或在订购过程中进行交易和/或阻塞。

Answer 2

验证使用其他模型的事件的选项有哪些？

domain event从业务的角度来看，A是一个重要的事件。这是过去发生的事情，所以无法改变。在 OO 中，它通常表示为Value Object，也就是说，一个不可变对象，其中有趣的部分是它们的属性。

通常，这些Domain Events是从Aggregate Root（DDD 术语）中的操作产生的。的客户端Aggregate Root是Application Service（又名用例）。Application Service接收一个对象并以此为Command基础，在Aggregate Root.

验证可以包括原始验证、对象验证和/或组合对象验证。那么负责执行此验证的对象应该是其Aggregate Root自身和/或具有特定验证目标的某些对象。

将购物车物品添加到购物车时，应该检查该物品是否尚未售罄

按照您的示例，对象将是：

• 命令：AddItemToShoppingCartCommand。保存有关要添加的项目的信息，例如购物车标识符。
• 应用服务：AddItemToShoppingCartService.
• 聚合根：ShoppingCartInventory。我故意Inventory在名称中使用以明确表示这Aggregate Root满足不变量“......如果该项目尚未售罄”。

注意：在我看来，检查库存的不变量Aggregate Root使 Aggregate 太大。我的建议是放松这个不变量，如果这个“售罄”它不是正常发生的话，拥抱最终的一致性。