我正在开发我的第一个 Axon 应用程序，但我无法弄清楚聚合的用途。我知道每次调用命令处理程序时，所有事件都会重新创建聚合，但我不明白重新创建聚合可能有什么其他用途。
我设置应用程序的方式是使用聚合视图将我需要的数据保存到数据库中。所以现在我觉得事件只是存储在事件存储中，仅在我调用命令后用于重新创建聚合。对于存储的事件和聚合的重新创建，我还有什么要做的吗？例如，我不应该重新创建整个聚合，而不是通过 ID 从我的数据库中获取聚合视图来更新它。
【问题讨论】：
标签： java events aggregate axon
Event Sourcing your Aggregate 背后的想法是，这些事件是您系统中任何模型的来源。
因此，如果您创建一个专门的命令模型来处理您描述的命令，那么这个模型（从 Axon 的角度来看是 @Aggregate(Root) 注释类）将来自它已发布的事件。
此外，您可以引入任何类型的查询模型；一个 RDBMS 视图、一个基于文本的搜索解决方案（例如 Elastic）、一个时间序列数据库，等等。但是，这些查询模型中的任何一个仍然是您的聚合所在的同一根应用程序的一部分。由于您将事件作为通知其他人正在做出的决定的手段，因此很自然地（重新）使用这些事件来更新您的所有查询模型也是。
现在，您完全不倾向于在 Axon 中为您的聚合使用事件溯源，这是完全正确的，从它的角度来看，它被称为 State-Stored Aggregate。但是，如果您这样做，您将回到在不同的存储机制中拥有不同的模型，而没有单一的事实来源。
所以，用这些额外的知识回到你的问题，我会陈述以下内容：
比如我应该什么时候手动重新创建聚合？
您永远不会倾向于将聚合重新创建为命令模型，因为框架会为您执行此操作。如果您有一个镜像查询模型聚合，那么只要您在模型中添加/删除/更改了字段，您就会重新创建它。或者，如果您引入了全新的模型。
每次调用命令时重新创建聚合有什么好处？
每次都重新创建它的好处是确保您将始终使用最新状态。即使在您的应用程序发布之间您已经添加/更改/删除了新字段。 @EventSourcingHandler 注解的方法将简单地填写它们，而不需要您例如编写数据库脚本来直接在数据库级别对其进行调整。
最后，采用这种方法的原因完全在于 Axon 支持的架构概念。如果需要，您可以在 AxonIQ 的 Architectural Concepts 页面上阅读它们；我相信它会进一步澄清事情。
希望这对您有所帮助@Gisrou8！如果没有，请回来提出更多问题，我很乐意进一步解释。
更新：进一步的命令模型解释
在 Gisrou8 在我的回复下的评论中，很明显这种方法的“不安”主要存在于聚合的状态。
正如我在之前的回复中所分享的，可以使用 Axon 框架建模的聚合在事件源设置中应该被视为 CQRS 系统中的命令模型。
命令模型的主要支柱之一是它包含的唯一状态是决策逻辑所需的状态。更具体地说，存储在聚合中的唯一状态是用于决定命令处理程序是否应接受传入命令并作为结果发布事件的状态。
因此，您将在聚合标识符旁边引入的唯一字段是推动这些决策所需的字段。 这就是命令模型的用途，所以不要担心这一点。
要回答应用程序中的任何查询，您需要引入一个专用查询模型，该模型会根据聚合中的命令处理程序发布的事件进行更新。正是这种精确的隔离是该模型的强项，因为它允许更好的扩展、性能改进或所需的团队分离，以及其他非功能性需求。
【讨论】：