使用 CQRS 和 ES 跨多个聚合的命令

Question

我在考虑解决我的问题时遇到了一个奇怪的案例。

快速回顾一下：我正在使用带有 CQRS 的事件存储，并且我有 2 个名为“组”和“用户”的聚合。

基本上，用户会定义一些特征，例如他的地区、年龄和一些兴趣。

然后他可以选择“匹配”与同一地区、大约相同年龄和相同兴趣的组。

现在的情况是：“匹配”部分应该完全在后端发生，这可能是一个长时间运行的过程，但对于客户端来说，它只是对端点的 1 次调用，最终结果应该是他与一个组匹配.

所以对于这种情况，我必须查询具有相同区域、相同年龄切片的组，兴趣在我的查询中并不重要。我知道有一个群组列表，媒人会根据群组和用户之间的共同兴趣给每个群组打分。评分最高的组将加入。

同样，使用 CQRS 和 ES，我的问题是这种情况似乎是查询和命令之间的混合，并且将查询混合到匹配命令中似乎违背了 CQRS 的目的。

查询多个组并针对我的写入端（事件存储）过滤它们也是一个坏主意，因为必须重新构建聚合并将它们加载到内存中才能过滤掉它们。

所以我有点卡在这里，有些东西告诉我长时间运行的进程/传奇可能是我的问题的答案，但我不明白我仍然不会破坏查询和命令的混合我的传奇，因为传奇基本上是一系列命令/事件。

我该如何处理这种特殊情况？不需要真正的代码，一个让我开始的概念性解决方案是完美的。

Answer 1

您好，这实际上是 CQRS 可以大放异彩的一个案例。

创建一个专门的匹配模型似乎是这种情况下的理想选择，以允许以其他形式回答可能是相当重要的查询。

所以，

1. 创建一个专用的（可能是短暂的，可能是检查点/持久的）查询模型作为派生存储。
2. 根据请求运行查询以获取热门匹配项。
3. 根据查询结果发送命令以使用新链接更新事件存储。

查询模型不需要管理命令，并且可以从事件存储中推送更新。这将使构建和保持更新变得相当简单，并且可以进一步优化以仅具有此特定查询所需的数据。

内存中的图表可能会做得很好。

-克里斯

附言

在命令方面：这里的命令每个只会更新一个聚合实例。

进一步使用预写模式将允许不需要任何类型的进程管理器或“saga”。

例如

对于每个新成员 1 个命令将新成员添加到用户流，然后 1 个命令到组以添加新成员信息。然后，一个简单的审计过程可以在启动/恢复时扫描不完整的成员分配，并作为定期数据质量检查。

-克里斯