事件驱动架构中的主题粒度答案

【问题标题】：Topic granularity in event driven architecture事件驱动架构中的主题粒度
【发布时间】：2019-03-06 21:56:06
【问题描述】：

我想知道在事件驱动的面向服务架构中主题名称的粒度应该是多少。

假设我们有一个用户管理系统，用户可以在其中执行不同的操作，例如注册、登录、修改某些配置文件属性等。如果我们想通知其他服务这些更改，我可以想到一些主题命名的可能性：

每个模型中的每个经典 CRUD 操作都有一个主题（不包括读取，因为用户的状态没有改变）。我们会有user-created、user-updated、user-deleted。这种方法足够通用，但可能会有许多服务订阅user-updated 主题并丢弃所有不修改特定字段的事件。
每个业务相关更改一个主题。除了user-created 和user-deleted，我们还可以有user-email-updated、user-signed-in 之类的事件（否则将作为user-updated 事件触发，其中上次登录的日期已更改）等。我的感觉是，即使对于那些只对非常具体的更改感兴趣的订阅者来说它会很方便，但对于那些需要同步用户发生的任何事情的服务来说，这将更加困难，因为他们必须订阅越来越多的跟踪用户模型中所有变化的主题。
1 和 3 之间的混合，其中user-updated 和 user-email-updated 将在用户更新电子邮件时发送，但如果用户更改配置文件将仅发送 user-updated。

【问题讨论】：

选项 2 是您的最佳选择，您可以从中获取上下文的业务事件。我的 2 美分，很高兴进一步讨论
@SeanFarmar 感谢您的评论。我在这里看到的缺点是，对于模型中的某些更改，除了将新值同步到服务的其余部分之外，可能没有进一步的操作。我认为模型中可能有很多变化需要在服务之间同步，但相关性不足以让它们自己拥有一个主题。您对如何处理这个问题有任何进一步的想法吗？
基于主题的路由不是做事件驱动系统的先决条件。我会看一个服务总线架构，其中路由是发布-订阅和分散的。

【解决方案1】：

可行的方法是实现第二个选项，但使用主题层次结构来实现它，以允许订阅者选择他们感兴趣的粒度（如订阅 users.* 或 *.updated 或 user.actions.login 等。 )

某些技术（例如 RabbitMQ）内置了此功能，对于其他技术，您可以实现主题注册表并提供基础架构来自己管理订阅

【讨论】：