Experimenting with Event Sourcing and CQRS where it matters
A few months ago I upset some people with some tweets about CQRS, Event Sourcing and my views on applying those techniques in certain domains:
Dear [PHP] community, repeat after me: User management is NOT a domain you should model using CQRS and event sourcing unless you plan to enter the market for general purpose authentication and authorization software.
Repeat the above for all other domains that are NOT your core domain.
Start at the end to prevent wasting your precious time and money on things that will NOT make a difference in your success.
Guess what. The tweet lacked nuance and proper explanation due to the well known character limit of the medium. So I started to reply to people to clarify my point of view.
In the original tweet I tried to point out that we should apply techniques in a context where they can provide value. Even when we are learning new techniques. In order to clarify I rephrased:
I know a handful of companies that have wasted their management buy-in on CQRS and ES because they started with it on trivial domains. The cost to maintain it in the longrun is substantial. So is replacing it. Obviously there are exceptions but IMHO there is too much cargo cult..
This was still misunderstood so I experimented with different words:
[Exactly. ]I never said you can’t, I said you should NOT. UNLESS it’s a contributing factor to your competitive advantage or part of your marketable offering.
Unfortunately the thread was beyond saving and it kept nagging me. Time to turn this into what it should have been: an article.
The bigger picture
It is important to think about the bigger — organisation-wide — picture whenever we want to experiment with new software design techniques. This is NOT about asking permission whenever we want to change our approach to software design. It is rather about increasing our chances of success when doing so.
The goal of good software design is to deliver value at a more predictable, faster and sustainable pace. So we must start with value first if we want to get buy-in from the organisation when we are doing things in new and exciting ways.
Small gains can prove value. Small losses are just that, small losses. That means you should:
- Identify something valuable;
- Size scope to smallest possible unit;
- Ensure a safe-to-fail environment;
- Experiment & learn from it;
- Evaluate & move on;
In the context of my tweetstorm that means applying Event Sourcing & CQRS in an area where there is large value potential. That isn’t just the core-domain and could be a supporting sub-domain as well (in my tweet I left that out because I felt this would de-emphasize the message that I was trying to get across). It means finding something that isn’t too large in scope.
Sources of value potential & appropriate scope
User-management often isn’t the source of tremendous value potential. Unless it powers the competitive advantage of the organization or when it is part of the marketable offering of the software.
You could say that the ‘training industry’ and ‘open source community’ aren’t doing you a favor when they are showing ‘user management’ or ‘customer registration’ as examples of applying CQRS & Event Sourcing.
Nor are the examples that show you entire applications built with the “CQRS & EventSource all the things”-mindset. That is because most of the examples I have seen lack an explanation to the student that CQRS & Event Sourcing are NOT top-level architectural patterns.
“Greg Young at DDDEU 2016: CQRS/ES is NOT a top level architecture!” by Marijn Huizendveld is licensed under CC BY 4.0
Am I saying you should never apply CQRS and Event Sourcing across the board? No, there are situations where doing so is merited. For example when your team is fluent in applying these techniques and after you have invested considerable resources – over time – in custom tooling. But in the context of my Tweets that is NOT the case.
What is a safe-to-fail environment for CQRS & Event Sourcing?
The problem with User-Management as a target area for learning is that it often isn’t safe-to-fail.
Let us assume for a moment that there is value potential. Great, but what if our experiment goes of the rails? User-management is right there in the midst of your daily operation. If you make a bunch of mistakes it will be costly and time intensive to fix. Or worse, what if our approach was entirely wrong and we see that we want to remove our solution completely?
In case we fail we would have to go back to decision makers and ask for additional time in order to discard what we have made. That is often costly in terms of political capital.
Perhaps this article squashed your dreams and you’re now left to wonder what you’re supposed to do alternatively. Here is my recommendation: don’t try to find problems for CQRS & ES but rather wait for an opportunity to present itself.
If you are operating in a domain where time is of the essence the problem will find you. At that point it is your job to evaluate the risk profile of your use-case together with domain experts and your team.
Only apply CQRS & ES when there is value potential and if you have means to mitigate the impact of getting it wrong.
Ideally your first try is not something that is part of your day to day business operation. If you must insist, build in an escape latch in the form of a feature flag so you can switch back to the old solution. All stakeholders must understand the risks and impact and accept the potential consequences.
Do you still disagree with me? Let me know on Twitter or contact me personally.