There seems to be endless debate about whether commands should or should not have return values. I would like to know if the debate is simply because the participants have not stated their context or circumstances.
Taking a cue from Jimmy Bogard's "CQRS Myths," I think the answer(s) to this question depends on what "command quadrant" you are speaking of:
+-------------+-------------------------+-------------------------+
| | Real-time, Synchronous | Queued, Asynchronous |
+-------------+-------------------------+-------------------------+
| Acceptance | Exception/return-value* | Exception/return-value* |
| Fulfillment | return-value | n/a |
+-------------+-------------------------+-------------------------+
Here, command "Acceptance" mostly refers to validation. Presumably validation results must be given synchronously to the caller, whether or not the command fulfillment is synchronous or queued. Assuming the responsibility for validation belongs to the command handler, it is then just a question of whether the validation result is supplied from the command handler as a return value (status code, enum, or Error message) or an outright exception.
That said, I presume it is "fulfillment of commands" where most of the debate and confusion is coming from regarding return values.
Regarding fulfillment, in a real-time setting it seems that a return value makes the most sense; exceptions should not be used to communicate business-related failure outcomes. However, in a "queuing" context...return values make no sense.
Have I correctly captured the essence of the confusion? Or am I not grasping some larger issue?
Aucun commentaire:
Enregistrer un commentaire