为什么与eventSourcing结合更新聚合实例很重要？

Question

我只是试图取消CQRS应用程序中的数据流。我知道有很大比例的机会，但有一点对我来说是个问号。

情景: CQRS与事件采购。

在您处理了聚合中的命令之后，就会触发这些事件。

现在，我的问题是:为什么我必须在我的汇总中再次应用该事件。

public void Apply(TabOpened e)
{
    open = true;
}

所以它寻找我遵循的过程

1. 发送命令
2. 总计验证命令
3. 从Aggreate/Commandhandler处理程序发送事件
4. 从事件流构建聚合实例
5. 事件应用于新更新的聚合。
6. 将新事件存储到Eventstream
7. 再次销毁实例

当用户希望看到更新的聚合时，我认为有以下数据流

1. 请求特定聚合
2. 使用Read-Model获取最新版本的聚合
3. 表集

现在我的问题是:再次将事件应用于新构建的聚合有什么好处。现在又开始验证了。这肯定是无用的工作。

谢谢你们！

Answer 1

总结:在应用命令时，通常加载聚合。然后要更改聚合的状态，这意味着添加了一个事件。我相信您的问题是:为什么要将事件应用于您的聚合，而不只是将事件附加到事件存储中，因为您以后会丢弃聚合？

你是这个意思吗？

它基本上只是验证了在下次重新加载聚合时，您将写入事件存储的内容是否能够并将被正确应用。在处理正在更改聚合的命令时，als可能需要采取多个步骤。第一步可能更改状态并更改第二步的输出。

Answer 2

现在，我的问题是:为什么我必须在我的汇总中再次应用该事件。

因为您希望聚合的表示形式的本地副本与您编写的持久存储匹配。

考虑以下顺序

1. 我给你发命令。
2. 你给我发了这条命令的回执。
3. ?？?
4. 我给你发了个问询。
5. 你给我发了个问询。

我们希望您的服务具有的属性:步骤5中的查询响应应该是相同的，无论第三步是无操作还是服务重新启动。

无论您是否使用“事件源”作为从一个服务实例到下一个服务实例之间通信状态的持久性机制，该属性都是可取的。

所以它寻找我遵循的过程

1. 总计验证命令

实际上，应该跟踪两种不同的验证形式。第一个问题是您的命令是否格式良好；消息中的所有字段是否都具有正确的形状，是否存在所有必需的字段，等等。这些都是您可以不考虑聚合的当前状态的检查。

当聚合处于其当前状态时是否允许此命令是一个单独的概念。

1. 从Aggreate/Commandhandler处理程序发送事件

事件应该写入事件流，然后才能在模型之外看到它们(步骤6)。

1. 再次销毁实例

你干吗要干那种事？当然，您可以从本地缓存中排除聚合实例；毕竟，您拥有恢复流中的状态所需的所有事件。但这不是必需的。