CQRS - can EventListener invoke Command?

Question

I want to use elements of CQRS pattern in my project. I wonder if i do it right with Command and Events. The thing that I'm not sure is if event can invoke command. To better show what i want to do I will use diagram and example.

This is an example:

User invoke TripCreateCommand. TripCreateCommandHandler do his job and after success publish TripCreatedEvent.

Now we have two listener to TripCreatedEvent (the order of listener execution does not matter)

First listener (can be execute after the second listener):

for each user in trip.author.friends invoke two Command (the order of commands is important)

1. PublishTripOnUserWallCommand
2. SendNewTripEmailNotificationCommand
3. SendNewTripPlatformNotification

Second listener (can be execute before the first listener):

1. PublishTripOnUserSocials

And this is sample diagram:

Is this a good way ? Can EventListener invoke Command, or maybe I should do it in some other way ?

Answer 1

Your question is about Mesage Driven Architecture which works together with but otherwise unrelated to CQRS.

Anyway, your diagram is almost correct. The event subscriber/handler (I prefer this terminology) can send new Commands via the service bus, but it's not a rule that you should always do this. I implement quite a lot of functionality directly in the event handler, although probalby would be more clean and reliable to send a new command. It really depends on what I want to do.

Note that the message handlers (commands or events) should not know about other handlers. They should know about the bus and the bus takes care of handling. This means that in your app, the event handlers would take the bus as dependency, create the command and send it via the bus. The event handler itself doesn't know what command handler generated the event and can 'reply' to it.

Usually the commands would be handled independently and you can't guarantee the order (unless they're handled synchronously) so maybe you want the second command to be issued as a result of the first command's handling. Indeed, it can be the case for a Saga.

AFAIK you are talking only about doing things synchronously, so your approach works in this case but it's probably not scalable. Moving to async handling will break this execution flow. However your application can be fine with it, not everyhting needs to be twitter.

A message driven architecture is not that straightforward and for some cases (like you want an immediate response from the backend) it's quite complicated to implement, at least more complicated than with the 'standard' approach. So maybe for those particular cases you might want to do it the 'old' way.

If you're worried about decoupling and testing, you can still design the services as they were message handlers but use them directly, instead of a service bus.