- Identifying Commands & Events
- Correlating Commands & Events
- Idempotent Commands
- Idempotent Events
If you are familiar with CQRS, then you may have run into these issues as well. If you are not completely familiar with CQRS but have heard of it, to be clear, I’m not talking about Event Sourcing, Domain Driven Design, or having multiple data stores or any of the overly complex version people think it is.
I’m simply talking about splitting up incoming requests into commands and queries.
Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value). – Greg Young
Identifying Commands and Events
Since commands are simple objects that can be serialized. I often will log the inbound command if there is a failure in the command handler.
This is really helpful for debugging failed commands as I can view the failed commands and retry them in my development environment for troubleshooting.
But it doesn’t stop there.
If you are emitting Events from your Command Handlers or Domain, it is often helpful to keep track of which Command caused which Event.
For a simplified version we can accomplish this with:
If needed, we can now wrap our commands in an Envelope before sending to the mediator.
Correlating Commands & Events
Now since we have wrapped our inbound command in an Envelop that contains a MessageId, in our Handler when emitting events, we can now add the MessageId from the Command to the CorrelationId of the new Event.
Next I’ll look at how I can use the Envelope for creating idempotent commands that do not contain a natural way of doing so.
How about you?
Do you apply a similar pattern as well? I’d love to hear about other implementations or uses. Comment below or on twitter.