Hello there,
I’m new to Axon Framework and I’m working on a project that uses it.
In this project, for every change in an aggregate, they use a command, even if the command does nothing except sending an event. I told them that this approach was unnecessary and that it would be more readable and efficient to use events directly.
They pointed me to the documentation where the IssueCardCommand does the same thing. But the documentation shows this just because it’s used for the constructor, right?
I’m not quite sure what you mean. I’m far from an authority, but event sourcing is based on “commands → events” - the point of commands is literally to spawn events, and most often events make changes in the aggregate. Unless I misunderstood your point, it sounds like your peers are absolutely correct in their assessment: if you want to make changes to an aggregate, you send a command to create an event to change it.
I think this depends on what the trigger for the change is. If the change is triggered by an external event, it would be strange to turn it into a command, just to generate another event from the command. However, if the change is triggered by some other action like an HTTP call, it might be more appropriate to treat it as a command, even if the command handler only emits an event.
There is nothing inherently wrong with publishing an event without any business validation. Hence, any command handler that simply maps the fields to 1 or several events is a perfectly valid use case. Assuming that the domain is expected to act like this!
Granted, it is good to take a careful look at the command handlers for sure. Doesn’t hurt to validate if there really is not business logic to be executed on those command handlers.