Should I put command bus between controller and domain service?

Question

I am working on a backend and try to implement CQRS patterns. I'm pretty clear about events, but sometimes struggle with commands.

I've seen that commands are requested by users, or example ChangePasswordCommand. However in implementation level user is just calling an endpoint, handled by some controller.

I can inject an UserService to my controller, which will handle domain logic and this is how basic tutorials do (I use Nest.js). However I feel that maybe this is where I should use command - so should I execute command ChangePasswordCommand in my controller and then domain module will handle it?

Important thing is that I need return value from the command, which is not a problem from implementation perspective, but it doesn't look good in terms of CQRS - I should ADD and GET at the same time.

Or maybe the last option is to execute the command in controller and then emit an event (PasswordChangedEvent) in command handler. Next, wait till event comes back and return the value in controller.

This last option seems quite good to me, but I have problems with clear implementation inside request lifecycle.

I base on https://docs.nestjs.com/recipes/cqrs

Answer 1

As your architecture evolves, you may find that you require a command bus if you are using Processes/Sagas to manage workflows and inter-aggregate communication. If and when that is the case, it will naturally make sense to use that bus for all commands.

The following is the method I would prefer:

execute the command in controller and then emit an event (PasswordChangedEvent) in command handler. Next, wait till event comes back and return the value in controller.

As for implementation details, in .NET, we use a SignalR websockets service that will read the event bus (where all events are published) and will forward events to clients that have subscribed to them.

In this case, the workflow would be:

1. The user posts to the controller.
2. The controller appends the command to the command bus.
3. The controller returns an ID identifying the command.
4. The client (browser client) subscribes to events relating to this command.
5. The command is received by the domain service and handled. An event is emitted to the event store.
6. The event is published to the event bus.
7. The event listener subscription service receives the event, finds the subscription, and sends the event to the client.
8. The client receives the event and notifies the user.