我想知道在事件驱动的面向服务的体系结构中主题名称的粒度应该是什么。
假设我们有一个用户管理系统,用户可以在其中执行不同的操作,例如注册,登录,修改某些个人资料属性等。如果我们想将这些更改通知其余服务,我可以想到一些主题命名的可能性:
每个模型中每个经典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
更改配置文件。
答案 0 :(得分:1)
方法是实现第二个选项,但以主题层次结构实现它,以使订户可以选择自己感兴趣的粒度(如订阅用户。*或* .updated或user.actions.login等。 )
某些技术(例如RabbitMQ)具有内置的此功能,对于其他技术,您可以实现主题注册表并提供基础结构以自行管理订阅