Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Once I started down the path of segregating commands and queries, I soon enough ran into a few issues that I needed to solve.
- 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.
In Microsoft’s Patterns & Practices CQRS Journey
, they created an Envelope<T>
to accomplish this.
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.
7 thoughts to “Identify Commands & Events”
In one of systems I was responsible for I created a small Fody plugin emitting WebAPI controllers. As the binding between request and the message (let’s not distinguish command/event for now) was pretty straight forward, I wanted to be able to have one way of handling messages, coming either from the user or from the system itself.
I truly do like the approach of cutting of the Web layer as soon as possible to focus on handling strongly typed requests. It liberates you from testing plenty of controllers leaving much more for better organized handlers.
Thanks for the comment. I’ve yet to use Fody however I have heard from several people having a good experience with it. I’d like to hear more about other usages. Do you have any blog posts or related info?
I’d more than happy to share some info:) The first and foremost the Fody docs are extremely well written: https://github.com/Fody/Fody/wiki
As you asked, I’ve written an article that will be published here https://blog.scooletz.com/2016/04/01/using-fody-to-provide-common-parts-for-structs/ (in 3 hours).
If you’re looking for some actual usage as well, the project I’ve described in the post can be found in here: https://github.com/Scooletz/RampUp/blob/master/src/RampUp.Enveloper.Fody/ModuleWeaver.cs
Nice! Thanks again.