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