I’m experimenting with Axon and see that in most examples of Create/Open/New Commands the ID of the aggregate the CommandHandler is creating is already contained in the command itself.
Now, from a SOC concept, the UI/Client should not care about the ID any object is getting. Also, it is very dangerous to let a client define a “unique” identifier. Hence the benefits from a preset ID is testability (Tell don’t ask).
Still I think API cleanliness should prevail. What do guys think?
I prefer client-generated identifiers. By using UUID’s you can guarantee unique values. Failure to provide a unique value will result in an exception.
The advantage is that routing of create commands becomes much easier. In a distributed environment, you can route the command to the machine that will “Host” that particular aggregate. It also allows a client to send a create and some update commands without needing to wait for the response of the first.
Towards “clients”, I hardly ever expose the command bus directly. I provide a thin API layer that acts as a gateway to the command bus. That gateway also generated the necessary identifiers.