EDA：“级联”事件还是显式命令？

Question

场景

假设我有一个系统的三个主要组成部分：

1. UI -从用户收集输入并创建通过消息总线发送的LoginUserCommand。然后，用户界面侦听MessageReceivedEvent的消息总线。
2. 用户服务-接收LoginUserCommand并引发UserLoggedInEvent。这里的关键部分是需要告诉消息服务开始接收消息。
3. Message Service -为登录用户引发MessageReceivedEvent。

选项

我的设计问题是关于用户服务和消息服务之间的交互。

当用户登录到一些需要发生的事情时--服务需要协调，以便UI开始接收消息。

我该不该..。

• 用户服务是否引发UserLoggedInEvent并让消息服务侦听此事件并执行用户接收消息所需的工作？

...or...

• 让用户服务引发一个UserLoggedInEvent，然后创建一个命令- StartMessageReceivingCommand，并将其显式地发送到消息服务

问题

每种方法的好处是什么？(级联事件与显式命令)。还有其他选择吗？

Answer 1

如果您的服务是真正的服务，只需引发一个userloggedinevent，然后让"message“决定下一步该做什么。如果用户已经登录，用户服务应该不了解需要开始接收消息的消息服务。只需引发事件，让每个订阅者自己决定下一步该做什么。

Answer 2

这对我来说没什么意义。UI本身不是一个逻辑服务。

由MessageReceivedEvent消息服务发布的消息是否足够公开，以至于任何UI都可以订阅该提要？如果没有，那么这些消息可能根本不应该发布。

如果用户不允许处理MessageReceivedEvent，除非它们已登录，那么这就是用户/安全服务的响应性，以确保这种情况不会发生。

如果MessageReceivedEvent确实需要发布，那么为什么不让用户服务在UI进程中运行呢？

1. UI流程订阅(向消息服务发送订阅请求)到MessageReceivedEvent
2. UI发送一个LoginUserCommand到用户服务的端点并在本地处理UserLoggedInReply
3. MessageReceivedEvent在UI流程中有两个处理程序
   • 第一个处理程序属于用户服务，如果用户未登录，则调用。
   • 第二个处理程序属于实际使用MessageReceivedEvent的一些有用的其他服务。

​

在步骤3中，当用户登录时，第一个处理程序是no。如果用户未登录，则第一个处理程序将完全停止其他MessageReceivedEvent处理程序的运行。

还有关于指定消息顺序here的更多信息

希望这能有所帮助