具有多个 id 的事件源和域事件

Question

事件溯源通常意味着每个聚合 ID 有一行：

事件_id	事件类型	实体类型	实体_id	事件数据
102	订单已创建	订购	101	{...}
103	订单已更新	订购	101	{...}

但是，如果您有一些批处理操作会导致一系列事件，例如：

• “将 10 000 封电子邮件标记为已读”=> 10 000 个 EmailReadEvent
• “更新 10000 个设备的设备状态”=> 10 000 个 DeviceStatusUpdatedEvent

对于此类场景（在其他微服务中具有副本）：

• 我们应该将这 10 000 个事件存储在事件存储中吗？
• 我们是否应该向代理发布 10 000 个事件，并在订阅者端逐一消费每个事件？

这看起来很浪费资源，而且效率很低。不幸的是，我在网上找不到有关此特定主题的任何资源。 我现在的想法是将我的域事件设计为全部都有一个 id 列表，以防批量操作。 EmailReadEvent 将有一个电子邮件 ID 列表，而 DeviceStatusUpdatedEvent 将有一个设备 ID 列表。 对于事件存储也是如此，我会在entity_id 列中有一个 id 列表。

您对这种方法有何看法？有没有更好的方法来做到这一点？

Answer 1

每个事件一个聚合 ID 的限制并不是真正来自事件源：它来自以下事实：这些是聚合事件，这意味着涉及给定电子邮件/设备/等的每个事件。是在了解有关该电子邮件/设备/等的所有先前事件的情况下发出的。

您可以在没有聚合的情况下进行事件源（就像您可以在没有事件源的情况下进行聚合一样）。

事件也可能最终与多个设备/电子邮件相关联，并具有聚合的一致性优势：所有这些电子邮件/设备都可以“只是”同一聚合中的实体。在很多情况下，这实际上是可行的（例如，电子邮件收件箱或给定收件箱中一天内收到的所有电子邮件很可能是一个聚合体；同时需要状态更新的设备很可能属于同一个客户或部署到同一站点）。

作为一些旁注......

其他微服务中的副本

在我看来，这是一个潜在的强烈迹象，表明出现了问题，具体取决于“副本”和“其他微服务”的含义。我会警惕可能的暗示，即您正在组合想要在不同有界上下文中的想法，这意味着您可能会使很多事情变得比它们需要的更复杂。或者，这可能是由于技术限制迫使微服务数量超出了管理复杂性所需的数量。

在订阅者端一一消费每个事件

不一定有任何特定订阅者必须逐一消费事件的原因（某些技术选择可能会迫使您这样做：您可能会重新访问这些选择）。