axon - 简单 "CRUD"在 Axon 聚合上读取

Question

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

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

到目前为止所有标准内容。但是简单的GET /foos/{id}怎么样？ ？

该网址 /foo/{id}是我想在 POST /foos 的 Location header 中返回的内容 我希望这个 GET 返回 Foo 的所有详细信息 - 所有这些都被建模为 FooAggregate 的属性(FooSummary 可能返回列表的子集)

现在，Axon documentation suggests this :

Standard repositories store the actual state of an Aggregate. Upon each change, the new state will overwrite the old. This makes it possible for the query components of the application to use the same information the command component also uses. This could, depending on the type of application you are creating, be the simplest solution.

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

我的选择似乎是:

1. 忘记事件源并使用存储状态聚合方法，正如建议的“最简单”方法(我没有任何特定的需要事件源我的聚合 - 尽管我我绝对是事件来源我的预测

2. 将完整详细信息保留在我的 FooSummary 投影表中，并直接 GET /foo/{id}到那里的查询与 GET /foo-summaries 略有不同(或者，只需将其命名为 GET /foos 并返回摘要)

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

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

Answer 1

回答我自己的问题，但实际上答案来自与 Axon 的 Christian 的讨论。 (在接受我自己的答案之前，将将此问题保留几天，以便获得更好的答案:))

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

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

(感谢克里斯蒂安)