Logic in CQRS commands?

Question

Software design

In fact, the logic is either where the command was called or in the command itself.
I lean towards the fact that the logic should be in the team. it is not known where it is called from, it can be a listener, a controller, and more.

By logic, I mean, we have data to update the user account, we transfer data to the handle through a
command that serves as a DTO validator and perform the actions we already need in the handle. For example, we send a password change notification to the user if the password has been changed.

Or the logic should be in the place where the command is called, and in the command we perform simple actions, for example, saving the entity and sending an email. This will simplify the commands, make them smaller, albeit increase their number.

Interested in the distribution of responsibility, where, when, how and why? Also, which is easier to test?

Answer 1

You are confusing command and event .
Command : create, delete, change password, reset password, edit, sell, etc.
Event : user created, user deleted, user password changed, user password reset, user edited, item sold, etc.
The "send notification" command cannot be called in another command. Teams cannot call each other directly. In this case, you have a "user password changed" event. A Notification subscriber is attached to this event. This subscriber sends a message directly, or calls the same command, but the notification command.
All business logic should be in commands, entities, services and other classes. Everything related to the Domain Model layer from DDD will be business logic.