How we failed at writing our own CQRS Library
Sometimes a series of good decisions lead to an overall not so good result. This is the story of how reinventing the wheel is not always the best option.
First of all, what is CQRS?
Command and Query Responsibility Segregation or CQRS is a well known and well-described pattern by many authors like Martin Fowler, Greg Young and Udi Dahan.
All those authors describe better than me why, when and how to implement the CQRS Pattern. Over the years, many libraries have been developed to support that pattern. They usually rely on the mediator pattern. One good implementation of the pattern is the well-known MediatR.
Why did we decide to create yet another library?
At GSoft we strive for innovation. We like to do things our way. Over the years many different teams adopted CQRS as their main pattern to decouple reads from writes. It makes sense as most of the team works on Event Sourcing or at least Event Based system.
All those CQRS implementations were slightly different. Some of them use the MediatR library but some use their own implementation based on MediatR concepts and code.
Because this was such a widespread concept we decided to merge all those implementation into a single one that can be shared across all of our products.
One of the reasons that had driven the decision to create our own CQRS library was that MediatR didn’t support streaming result in queries at that time. Because we had that need, it made sense to capitalize on our existing CQRS implementation and add that support. That was our first mistake. Not long after (or even around the same time) that we added streaming functionality to our library, MediatR did the same.
The second mistake was to focus on publicly publishing our library to show the world our technical expertise. We let our ego drive our decision to continue on that path.
To reassure ourselves we even justified our decision by stating that there is no risk to use our own library because its contract is so close to MediatR that we can switch to it whenever we want. We should have realized then that it was foolish to pursue this endeavour.
Learning from our mistake
At the moment there is no plan to move to MediatR but this may change.
Sometimes, when you’re in the midst of it all, it’s hard to take a step back and see the bigger picture. We are often blinded by our own beliefs, we want it to work the way we imagined it.
Don’t get me wrong, we have a pretty sturdy library in our hands and we have the total freedom to shape it the way we like. The price to pay is not that much but we still have the responsibility to manage and support it, which is not our core business and can have a slight impact on our velocity to deliver product features.
What’s next?
In the future we must challenge ourselves before trying to build a library when some other already exist in the market.
We should be more careful and better follow one of our own engineering principles “Promote Reusable Solutions”.
If you are still curious to see how we built it, feel free to take a look at our CQRS Library. While are there you can browse our GitHub repo for others, we like to share.
