If ESDM really is such a good approach for your system architecture, why doesn’t everyone use it? (for those who haven’t read the previous articles, do so here)
Because it’s a paradigm shift in how engineers approach systems, it’s hard to understand and its hard to implement.
It takes effort to read, experiment and understand to effectively implement. The framework is where the complexity and confusion resides – and due to a lack of frameworks out there, YOUR engineers need to make one themselves.
And they probably haven’t read enough, or understood the important bits, and don’t know what they don’t know… so you end up with a mess. We learn in our own context – if we don’t get some important aspect and have that challenged by soak testing in real systems, we’re prone to work that mistake into our framework.
Reading new content, absorbing it in online videos or doing sit down courses do not necessarily lead to the understanding required to create such a framework. Even if it did, creating such a framework and maintaining it probably takes over 80% of the effort (based on my finger in the air; 80/20, shoot me!).
When I’ve heard people have “implemented DDD” or “implemented ESDM” and it was a mess, you need only look at what has been implemented to understand it was NOT ESDM or that key pitfalls in DDD and distributed event driven systems or event sourcing have been misunderstood, ignored or not realised as a thing to solve at all.
In the companies I’ve worked in over the last 10 years I’ve not seen a single one implementation ESDM or even event sourcing. It’s just crud based entity obsession and all the quadratic complexity and regret this approach generates.
What about Wolverine et al?
Yes, some lovely frameworks exist out there. But they are too open, too hesitant to have an opinion – or too restrictive on technology decisions. They demand deep understanding from engineers to make ESDM work over the top of them. There’s nothing custom made for ESDM (at least that I could find) that doesn’t come with a huge price tag or limits technology choice or vendor.
Let’s make it easier
If we could make it easier to implement ESDM such that it is more readily adopted, we’ll see more systems benefiting from it. And I personally want that – systems with significantly reduced regret, improved traceability, improved relationships with our customers and all the other benefits ESDM provides. That’s going to help the human race achieve the big goals it needs traction on over the next century.
We need an approach which is opinionated so engineers don’t need to be experts in the framework or the hidden complexities – they just implement commands, emit events and create view projections.
The framework should allow easy substitution of selected technology and vendor – use GC or AWS or Azure. Use your own on-premise text file if you want. Use SQL or Cosmos; just switch out libraries and connection strings.
And that is Cascade ESDM. An opinionated, C# backend implementation of ESDM that takes away all of the complexity of the approach, allowing engineers to focus on function (commands) and presentation (views).
It’s still early stages (beta) with an initial release available Q2 2026. Watch this site, get involved on our github and get the latest release from nuget.