问轴突重新聚集状态不清楚

EN

事件源聚合背后的思想是，这些事件是系统中任何模型的源。

因此，如果您创建了一个像您描述的那样处理命令的专用命令模型，那么这个模型(从Axon的角度来看就是@Aggregate(Root)注释类)将来自它发布的事件。

此外，您还可以向介绍任何类型的查询模型；RDBMS视图、基于文本的搜索解决方案(例如弹性)、时间序列数据库，您可以给它命名。然而，这些查询模型中的任何一个仍然是您的聚合所在的同一个根应用程序的一部分。由于您将事件作为通知其他人正在作出的决策的手段，因此使用这些事件来更新所有查询模型也是很自然的。

现在，完全正确的是，您不倾向于在Axon中为您的集合使用事件源，从它的角度来看，事件源被称为状态存储聚合。但是，如果您这样做，您将回到在不同的存储机制中拥有不同的模型，而没有一个真实的来源。

因此，为了回过头来回答你的问题，我要说明以下几点：

比如何时我应该手动重新创建一个聚合？

您从不倾向于将聚合重新创建为命令模型，就像框架为您所做的那样。如果您有镜像查询模型聚合，那么您将在模型中添加/删除/更改字段时重新创建这个集合。或者，如果你引进了全新的车型。

每次调用命令时重新创建聚合的好处是什么？

每次重新创建它的好处是保证您将始终使用最新的状态。即使在应用程序发布之间添加/更改/删除了新字段。@EventSourcingHandler注释的方法可以简单地填充它们，而不需要编写数据库脚本来直接在数据库级别上对其进行调整。

最后，采用这种方法的原因完全在于Axon所支持的体系结构概念。如果你愿意的话，你可以在AxonIQ的建筑概念页面上读到它们；我相信它会进一步澄清事情。

希望这能帮到你@Gisrou8！如果没有，请带着更多的问题回来，我很乐意进一步解释。

更新:进一步的命令模型解释

在我的回复下的评论Gisrou8中，很明显，这种方法的“不安”主要存在于聚合状态中。

正如我在前面的响应中所共享的，在一个事件源设置中，可以用Axon框架建模的聚合应该被视为CQRS系统中的命令模型。

命令模型的主要支柱之一是，它包含的唯一的状态是决策逻辑所需的状态。更具体地讲，聚合中存储的唯一状态是用来决定命令处理程序是否应该接受传入命令并因此发布事件的状态。

因此，您将在聚合侧引入聚合标识符的唯一字段是驱动这些决策所需的字段。这就是命令模型的目的，所以不要担心这一点。

要回答应用程序中的任何查询，您需要引入一个专用的查询模型，该模型是由于命令处理程序在聚合中发布的事件而更新的。正是这种精确的分离正是这个模型的强项，因为它允许更好的扩展、性能改进或所需的团队分离，以及其他非功能需求。