Software development is not an end in itself: A look back at 2025
From Artificial Intelligence to Event Sourcing: These are the topics I focused on particularly intensely in the blog this year.
(Image: amgun/Shutterstock.com)
- Golo Roden
Software development is not an end in itself but always follows an underlying domain logic.
This sentence, I feel, appears in every one of my blog posts here at Heise Developer. It is my guiding principle, my conviction, my compass. But 2025 was the year it gained more significance for me than ever before.
Why do so many software projects fail? Why do they become pricier than planned, take longer than promised, deliver less than hoped for? The answer I see again and again is not: “Because the technology failed.” The frameworks were good enough. The databases fast enough. The cloud scalable enough. No, the projects fail because the domain logic is forgotten. Because technology becomes an end in itself. Because database tables are designed instead of asking what is actually happening.
This year I tried to write against that. And not only that.
EventSourcingDB: The Consequence of the Thesis
In May of this year, we released EventSourcingDB, a database specifically designed for event sourcing. Not another NoSQL database, not another tool “for the sake of the tool,” but the technical consequence of a conviction.
Event sourcing forces you to think about domain logic. You don't store states, but domain events. Not “customer has address Y,” but “customer moved to the following address on March 15th.” This sounds like a small difference, but it is a fundamental change in perspective. The technology serves the domain, not the other way around.
I am pleased that EventSourcingDB has now recorded over 10,000 Docker downloads. But I am even more pleased that apparently more and more developers have been looking for exactly such a tool – a tool that takes domain logic seriously.
The Common Thread: The Most Important Articles of the Year
I published over 40 blog posts in 2025 here at Heise Developer. About event sourcing, about architecture, about AI, about agility and its pitfalls. But when I look back, seven of them form the core of what I'm really concerned about. Together, they tell a story: the story of why software development needs to be thought of differently.
Making the Problem Visible
I want to start with a fairy tale. In my blog post “Why CRUD is equally unsuitable for fairy tales and companies,” I tried to make a complex topic accessible through a simple metaphor: The wolf didn't delete Grandma – he ate her.
CRUD (Create, Read, Update, Delete) is the standard vocabulary of most applications. But it is a technical vocabulary, not a domain one. It hides what really happens. It reduces business processes to database operations. And it turns systems into black holes where the past disappears.
The fairy tale apparently struck a chord. Perhaps because every developer has stood before a system and wondered, “How did this data record actually get into this state?”
The Conceptual Foundations
If CRUD is the problem, what is the solution? I answered that in two articles: “Event Sourcing: The better way to develop?” and “CQRS as the basis for modern, flexible, and scalable application architecture”.
Event sourcing means not storing the state but the events that led to that state. CQRS means separating reading and writing because both have different requirements. Together, they form the building blocks for systems that take domain logic seriously. Systems in which you can trace what happened and in which you can ask new questions of old data.
The Deep Dive
Concepts are one thing; implementation is another. That's why I wrote a seven-part series in the summer: “Event-Driven.” From the limits of classic architectures to the building blocks of event-driven systems and practical implementation using the example of a city library.
It was my most comprehensive work on the topic this year. And it was important for me to show that event-driven architecture is not an academic concept but a practical way to build software that speaks the language of the domain.
Technical Depth in Service of Domain Logic
Anyone who talks about event sourcing must also talk about trust. How can I prove that a certain event occurred at a certain time? How can I guarantee traceability without having to disclose all my data?
In “Merkle Trees: Cryptographically Proving Data Integrity,” I showed how these questions can be elegantly solved. Merkle Trees are not a new invention. They are found in Git, in blockchains, in Certificate Transparency. But with event sourcing, they unfold their full strength: they make traceability not only possible but provable.
This is not a technical gimmick. It is relevant for compliance, for audits, for GDPR. Technology in the service of real requirements.
Questioning Sacred Cows
The last article in this series is the most recent and perhaps the most controversial: “Applying DDD to DDD leaves no domain driven design behind.”
Domain-Driven Design is something of a sacred cow in my community. And I greatly appreciate the basic ideas of DDD. But I also observe how DDD itself becomes self-indulgence. How teams define Bounded Contexts without ever having spoken to a domain expert. How aggregates and value objects become ends in themselves instead of serving the domain.
This is not a criticism of Eric Evans or of DDD as an idea. It is a criticism of how we as a community sometimes prioritize methods over results. And it is a plea to critically question even our favorite tools.
The Community: Not Alone on the Journey
As much as I write, in the end, it is the community that keeps these topics alive. And 2025 has shown me that I am not alone in my convictions.
In October, my colleague Rendani and I attended KanDDDinsky in Berlin – for the first time as sponsors and exhibitors for EventSourcingDB. 250 to 300 people who share our passion for Domain-Driven Design, Event Sourcing, and well-thought-out software architecture. The conversations there showed me: the topic has momentum. Event Sourcing and CQRS are no longer niche interests practiced by a small group of enthusiasts in isolated corners.
I was particularly pleased with the release of OpenCQRS 1.0 by Digital Frontiers, a CQRS and Event Sourcing framework for the JVM with native EventSourcingDB integration. An ecosystem is emerging. Others are building on the foundation. That is the greatest confirmation for the work one puts into a project.
And of course, I thank you, the readers, who commented, discussed, disagreed. Especially the controversial articles have shown me that the topic resonates. Disagreement is not a problem, indifference would be.
Outlook: Domain Logic, Architecture, and AI
Looking ahead to 2026, I see one topic that will overshadow everything else: Artificial Intelligence. But not in the way it is often discussed.
In my blog post “Event Sourcing as the perfect foundation for AI,” I argued that the discussion about AI too often starts with the models. Which LLM is the best? GPT or Claude? But that is the wrong question. The right question is: “What data do I have?”
An average model with high-quality data will outperform any top model trained on inferior data. And most companies' data is inferior because it resides in CRUD systems that only know the current state. The past? Overwritten. The context? Lost. Causality? Irreconstructible.
Event sourcing changes that. It provides context-rich, traceable data. It answers not only the question “What is?” but also “How did it get this way?” And that is exactly what AI needs.
At the same time, value creation in software development is shifting. In “AI makes developers replaceable, but not good architects,” I described what that means: coding is becoming a commodity. What remains is domain knowledge, architecture, modeling. This is not a downfall for our profession but rather an opportunity for all who take domain logic seriously.
The combination of architecture, domain logic, and AI will become increasingly important in the future. Those who understand how to build systems that produce good data, who understand how to use AI meaningfully, and who simultaneously understand the domain for which they are developing, will be in demand. It is precisely at this intersection that I am currently working on a webinar series for 2026: the tech:lounge 360°. For everyone who doesn't want to be overrun by AI, but wants to understand and use it.
In Conclusion
Software development is not an end in itself. That was my guiding principle at the beginning of this article, and it is my guiding principle at the end of this year.
2025 was the year for me when this sentence took shape: in EventSourcingDB, in over 40 blog posts, in conversations at conferences, in work with clients. It was an intense year, a productive year, and I am grateful for everyone who walked this path with me.
I wish you time between the years. Time to reflect on what the actual domain problem is that you want to solve. Time to pause and ask yourself whether the technology you are working with serves the domain logic or has become an end in itself.
And then a year 2026 in which technology will once again become what it should be: a tool in the service of that domain logic.
Merry Christmas, peaceful and relaxing holidays, and a happy new year. (rme)
