Question: a commandBus into a commandHandler = bug about php-ddd-example

[JavierCane]

Which is your use case?

When we have to split operations between different Bounded Contexts or Modules, we inject the Command or Query Bus in the Application Service (not the Command Handler). This way, we still encapsulate all the use case in the very same Application Service.

Example: Check if a Course exists before creating a Video referring to it. In this case we will inject the QueryBus in the VideoCreator service, making a FindCourseQuery and checking if the response is not null before actually creating the Video aggregate, saving it to the repository, and publishing the corresponding domain event.

This way, we would be encapsulating the whole use case as previously said, making it reusable without taking into account the entry point (we could be executing that very same use case based on a domain event, and we would still want to match all the preconditions without having to implement them also in the domain event subscriber).

If that makes sense to you, could you try injecting the Command/Query Bus into the actual Application Service to be executed and see if that works?

Thanks for the report!

[rgomezcasas]

Just a clarification, we don't inject the command bus in the application services or in another command handler, only in the controllers.
Why? Because our services only do 1 thing. If we need to do more, instead of publishing a command, we publish a domain event.

So, instead of doing something like:

1. UserPostController publish RegisterUserCommand
2. Is handled by its command handler and calls the Application Service
3. This application service register the user (insert in DB)
4. Then publish another command for Send a Welcome Email to the User
5. Then publish another command for giving the user a Welcome Bonus
6. And more and more commands every time we need to do anything when a user is registered

With this approach, we're violating the OCP principle given every time we need to extend our code we're modifying the Application Service.

We do something more like:

1. UserPostController publish RegisterUserCommand
2. Is handled by its command handler and calls the Application Service
3. This application service register the user
4. Then publish a UserRegistered domain event
5. Then another uses cases, atomically, can react to it (after being handled by a Subscriber)

With this approach we're respecting the OCP and also we have a reactive, more scalable and reliable system.

---

With this in mind, if you want to have services with the command handler injected (again, a thing that we don't recommend :P) and you want to avoid having that cyclic dependency, you need to do lazy all the application services.

[Axxon]

Thanks you very much for your complete response, finally i changed my way of doing, i created a console command (controller purpose), that dispatch a command to a handler. This handler then indirectly update the model of a different bounded context via domain Events. Like you explain i think.

[rgomezcasas]

👏👏👏👏

Peeerfect!! 😊

Have fun!!!