domain-driven-design - 如何使用 CQRS 和事件溯源处理依赖于应用程序中现有记录的命令

Question

我们将 CQRS 与 EventSourcing 结合使用。

在我们的应用程序中，我们可以从 ui 添加资源(这是单个项目的业务术语)，我们正在相应地发送命令以添加资源。

所以我们在应用程序中存在 x 数量的资源，这些资源是之前添加的。现在，我们有了一种特殊类型的资源(我称它为 SpecialResource)。当我们添加这个 SpecialResource 时，id 需要与应用程序中的所有现有资源相关联。Linked 意味着这个 SpecialResource 应该有 List of ids(guids) (List) of existing resources.

我们尝试在添加特殊之前获取应用程序中所有资源ID的解决方案资源(即在触发 AddSpecialResource 命令之前)。将这些List分配给SpecialResource，然后发送AddSpecialResource命令。

但我们不应该这样做，因为根据 cqrs 命令不应该查询。IE。命令不能依赖于查询，因为查询可能有陈旧的记录。

我们如何在不查询应用程序中现有记录的情况下实现这种业务场景？

Answer 1

But we are not suppose to do so , because as per cqrs command should not query. I.e. command cant depend upon query as query can have stale records.

这不太对。

“命令”始终运行查询。如果您使用事件溯源，在大多数情况下您的命令是查询——“如果允许此命令，将生成什么事件？”

这与您描述的情况之间的区别在于聚合边界，它在事件源域中是事件流的奇特名称。在处理命令时，允许聚合针对其自己的事件流(也就是说，它自己的状态)运行查询。超出范围的是其他聚合(事件流)。

实际上，这意味着 如果 SpecialResource 确实需要与其他资源 ID 在事务上保持一致，那么所有这些数据都需要成为同一聚合的一部分，因此也是相同的事件流，从那一点开始的一切都非常简单。

因此，如果到目前为止您一直在使用单独的流对资源进行建模，现在您需要 SpecialResource 才能像您描述的那样工作，那么您需要对域模型进行相当大的更改。

好消息:这可能不是您的真正要求。考虑您到目前为止所描述的内容 - 如果 resourceId:99652 在 SpecialResource 之前一毫秒创建，那么它应该包含在 SpecialResource 的状态中，但如果它是在一毫秒之后创建的，那么它不应该。那么，如果资源在 SpecialResource 丢失前一毫秒创建，企业的成本是多少？

因为，先验地，这听起来不像是应该太贵的东西。

更常见的是，真正的需求看起来更像是“SpecialResource 需要包含在营业结束前创建的所有资源 ID”，但实际上直到营业结束后 5 分钟才需要 SpecialResource。换句话说，您在这里有一个 SLA，您可以使用该 SLA 更好地通知您的命令。

How can we achieve this business scenario without querying existing records in application?

把它转过来；运行查询，将查询结果(资源 ID)复制到创建 SpecialResource 的命令中，然后分派(dispatch)要传递给域模型的命令。 CreateSpecialResource 命令在其中包含正确的资源 ID 列表，因此聚合无需担心如何发现该信息。