在 Axon 聚合上读取简单的“CRUD”

Question

在没有 AxonServer 的情况下，在 REST-Axon 程序中对聚合执行基本 GET 的最简单方法是什么？

• 我有一个带有聚合 FooAggregate 的简单 springboot Axon-and-REST 应用程序。
• 我使用POST /foos 创建 Foo，它在命令网关等上发送命令。
• 我通过实际查询GET /foo-summaries 来查询所有 Foo 的列表，这会在查询网关上触发查询对象，并返回 FooSummary 对象的位置，其中 FooSummary 是我在侦听 FooCreated 和 FooUpdated 事件的投影中创建的 JPA 实体.

到目前为止所有标准的东西。但是简单的GET /foos/{id} 呢？

那个 URL /foo/{id} 是我想在 POST /foos 的 Location 标头中返回的内容 我希望 this GET 返回 all 我的 Foo 的详细信息 - 所有这些都被建模为 FooAggregate 的属性（FooSummary 可能会返回一个子集以供列出）

现在，Axon documentation suggests this：

标准存储库存储聚合的实际状态。每次更改时，新状态都会覆盖旧状态。这使得应用程序的查询组件可以使用命令组件也使用的相同信息。根据您创建的应用程序类型，这可能是最简单的解决方案。

但这仅适用于我使用状态存储的聚合，对吗？我正在使用带有 JPA 事件存储的事件源聚合。

我的选择似乎是：

1. 忘记事件源并使用存储状态聚合方法，建议作为“最简单”的方法（我没有任何特定需要事件源我的聚合 - 尽管我肯定 事件采购我的投影

2. 将全部详细信息保存在我的 FooSummary 投影表中，并使用与 GET /foo-summaries 略有不同的查询将 GET /foo/{id} 定向到那里（或者，只需将其称为 GET /foos 并返回摘要）

3. 创建一个单独的“投影”来存储完整的 Foo 详细信息。这将实际上与我们在状态存储聚合中使用的相同，所以看起来有点奇怪。

4. 第四个选项 - 这个问题的原因是什么？

Answer 1

回答我自己的问题，但真正的答案来自与 Axon 的 Christian 的讨论。 （在接受我自己的答案之前，将开放几天以便获得更好的答案:)）

我的选项 #2 和 #3 是正确答案：差异取决于我的“摘要”投影与“详细”投影之间的差异。如果它们足够接近，选项 #2，如果它们足够不同 #3。

选项 #1 并不理想，因为即使我们出于某种其他原因使用状态存储，基于状态存储的查询也会破坏 CQRS 中的“S”隔离：它使我们的查询模型依赖在我们的命令模型上，当我们的模型变得更复杂时，这可能会导致问题。

（感谢克里斯蒂安）