domain-driven-design - CQRS 聚合

Question

我是 CQRS/ES 世界的新手，我有一个问题。我正在开发一个使用事件源和 CQRS 的发票 Web 应用程序。

我的问题是 - 根据我的理解，进入系统的新命令(假设 ChangeLineItemPrice)应该通过域模型，以便它可以被验证为合法命令(例如，检查该行项目是否实际存在，价格不违反任何业务规则等)。如果一切顺利(命令没有被拒绝) - 然后创建并存储适当的事件(例如 LineItemPriceChanged)

我不太明白的是，在尝试应用命令之前，如何将这个聚合保存在内存中。如果系统中有一百万张发票，每次我想应用一个命令时，我是否应该播放整个历史记录？我是否总是在没有任何验证的情况下保存事件并在构建 View 模型/投影时进行验证？

如果我误解了该过程的任何部分，我将不胜感激您的反馈。

谢谢你的帮助!

Answer 1

你并不孤单，这是一个常见的误解。我先回答验证部分:

在这种系统中有两种类型的验证。第一种是您查找有效电子邮件地址、仅数字或必填字段的类型。这种类型甚至在命令发出之前就完成了。包含此类问题的命令不应作为命令提出(对于腰带和大括号，您可以在域方面进行检查，但这不是域问题，您最好防止这种情况发生)。

下一种类型的验证是何时 是 域问题。这可能是您提到的那种检查价格是否在一组指定参数内的事情。这是业务人员会理解、执行并能够表达的领域概念。

下一阶段是域应用状态更改并引发相关事件。然后这些被持久化并成功后，为应用程序的其余部分发布。

所有这些都可以通过内存中的聚合来完成。这些操作与处理命令的域服务协调。它加载聚合，应用所有过去的事件(或加载快照)，然后发出命令。命令成功后，它会请求所有新的未提交事件并尝试保留它们。成功后，它会发布新事件。

如您所见，它仅加载该特定聚合的事件。即使有很多事件，这个过程也是闪电般的快。如果性能是一个问题，则可以应用一些策略，例如将聚合保留在内存中或快照。

关于验证事件的最后一点。由于它们只能由您的聚合生成，因此它们值得信赖。

如果您想了解更多详细信息，请查看我对 CQRS 和 ES 的概述 here .并查看我关于如何构建聚合根的帖子 here .

祝你好运 - 我希望他们有所帮助!