我不确定的是事件是否可以调用命令.为了更好地展示我想做什么,我将使用图表和示例.
这是一个例子：
用户调用TripCreateCommand. TripCreateCommandHandler完成他的工作,并在成功发布TripCreatedEvent之后.
现在我们有两个TripCreatedEvent监听器(监听器执行顺序无关紧要)
第一个监听器(可以在第二个监听器之后执行)：
对于trip.author.friends中的每个用户调用两个命令(命令的顺序很重要)
> PublishTripOnUserWallCommand
> SendNewTripEmailNotificationCommand
> SendNewTripPlatformNotification
第二个监听器(可以在第一个监听器之前执行)：
> PublishTripOnUserSocials
这是示例图：
这是一个好方法吗？ EventListener可以调用Command,或者我应该以其他方式执行它吗？
解决方法
无论如何,你的图表几乎是正确的.事件订阅者/处理程序(我更喜欢这个术语)可以通过服务总线发送新的命令,但是你不应该总是这样做.我直接在事件处理程序中实现了很多功能,尽管probalby在发送新命令时会更加干净和可靠.这真的取决于我想做什么.
请注意,消息处理程序(命令或事件)不应该知道其他处理程序.他们应该知道公共汽车和公共汽车负责处理.这意味着在您的应用程序中,事件处理程序将把总线作为依赖项,创建命令并通过总线发送它.事件处理程序本身不知道命令处理程序生成了什么事件,并且可以“回复”它.
通常命令将独立处理,你不能保证顺序(除非它们是同步处理的),所以你可能希望第二个命令是由第一个命令处理后发出的.事实上,佐贺可能就是这种情况.
AFAIK你只是在谈论同步的事情,所以你的方法适用于这种情况,但它可能无法扩展.转向异步处理将破坏此执行流程.但是你的应用程序可以很好用,不是每个人都需要推特.
消息驱动的体系结构并不是那么简单,对于某些情况(就像你想要后端立即响应),实现起来相当复杂,至少比使用“标准”方法更复杂.因此,对于那些特殊情况,您可能希望以“旧”方式进行.
如果您担心脱钩和测试,您仍然可以设计服务,因为它们是消息处理程序,但是直接使用它们而不是服务总线.