事件来源-事件流澄清

Question

我进入了一个微型服务项目，我面临着这个问题。假设您有一个由两个微服务组成的表预订服务：

• 餐厅服务(负责管理餐厅的名称、所有者、桌子等信息)。
• 预订服务(管理预订验证工作流)。

"Restaurant“实体的事件流非常简单: streamId是restaurantId，像"tableAdded”或"tableRemoved“这样的每个事件都有一个增量eventId。重播每一个事件并获得聚合都是微不足道的。

预订呢？我当前的事件流设计使用restaurantId作为streamId，每个事件(如"reservationAccepted“或"reservationRefused”)都附加到该流中。

负责确认预订请求的算法需要知道之前和之后的预订(在收到请求的预订时间后3小时内)。

尽管如此，不应考虑预订时间比现在更早的预订，也不应该重播它的事件，但是在此设计中，每个事件都会针对每个请求被重放。

概括地说，如果我要求预订明天，系统将重播6个月前的预订，这些预约通常与收到的请求无关，因为它们指的是过去的某个时刻。

随着时间的推移，这会导致效率低下，因为大量不必要的事件被重播。我想用每天的快照来解决这个问题，但这似乎是错误的。

有什么想法吗？

谢谢您的任何帮助！

Answer 1

当使用事件驱动时，我建议学习CQRS https://martinfowler.com/bliki/CQRS.html，这是谜题的一个重要部分。

简单地说，在单独的实体中保存与业务需求相关的事件的视图是合理的，您可以使用相关数据进行查询。

在您的示例中，有一个关于验证请求的业务要求，因此您可以根据事件构建一个表，在创建有效的新事件之前，您只需在最后3个小时的预订中请求该表即可接收相关信息。

这有时也被称为投影：https://dzone.com/articles/the-good-of-event-sourcing-projections

预测可以是

1. 当验证发生时计算(可能像您所说的那样效率低下)
2. 当与该投影相关的新事件发生时重新计算或更新。
3. 任何对你来说都有意义的选择。