Softwareentwicklung ist kein Selbstzweck: Ein Rückblick auf 2025

Softwareentwicklung ist kein Selbstzweck, sondern folgt immer einer zugrunde liegenden Fachlichkeit.

Dieser Satz steht gefühlt in jedem meiner Blogposts hier bei Heise Developer. Er ist mein Leitsatz, meine Überzeugung, mein Kompass. Aber 2025 war das Jahr, in dem er für mich mehr Bedeutung bekommen hat als je zuvor.

Warum scheitern so viele Softwareprojekte? Warum werden sie teurer als geplant, dauern länger als versprochen, liefern weniger als erhofft? Die Antwort, die ich immer wieder sehe, lautet nicht: „Weil die Technik versagt hat.“ Die Frameworks waren gut genug. Die Datenbanken schnell genug. Die Cloud skalierbar genug. Nein, die Projekte scheitern, weil die Fachlichkeit vergessen wird. Weil Technik zum Selbstzweck wird. Weil man Datenbanktabellen entwirft, statt zu fragen, was eigentlich passiert.

Dieses Jahr habe ich versucht, dagegen anzuschreiben. Und nicht nur das.

EventSourcingDB: Die Konsequenz der These

Im Mai dieses Jahres haben wir EventSourcingDB veröffentlicht, eine Datenbank, die speziell für Event Sourcing entwickelt wurde. Keine weitere NoSQL-Datenbank, kein weiteres Tool „um des Tools willen“, sondern die technische Konsequenz einer Überzeugung.

Event Sourcing zwingt zum Nachdenken über Fachlichkeit. Man speichert nicht Zustände, sondern fachliche Ereignisse. Nicht „Kunde hat Adresse Y“, sondern „Kundin ist am 15. März an folgende Adresse umgezogen“. Das klingt nach lediglich einem kleinen Unterschied, ist aber ein fundamentaler Perspektivwechsel. Die Technik dient der Domäne, nicht umgekehrt.

Dass EventSourcingDB inzwischen über 10.000 Docker-Downloads verzeichnet, freut mich. Aber mich freut noch mehr, dass offenbar immer mehr Entwicklerinnen und Entwickler nach genau so einem Werkzeug gesucht haben – einem Werkzeug, das Fachlichkeit ernst nimmt.

Der rote Faden: Die wichtigsten Artikel des Jahres

Über 40 Blogposts habe ich 2025 hier bei Heise Developer veröffentlicht. Über Event Sourcing, über Architektur, über KI, über Agilität und ihre Abgründe. Aber wenn ich zurückblicke, bilden sieben davon für mich den Kern dessen, worum es mir eigentlich geht. Sie erzählen zusammen eine Geschichte: Die Geschichte, warum Softwareentwicklung anders gedacht werden muss.

Das Problem sichtbar machen

Beginnen möchte ich mit einem Märchen. In meinem Blogpost „Warum CRUD für Märchen und Unternehmen gleichermaßen ungeeignet ist“ habe ich versucht, ein komplexes Thema über eine einfache Metapher zugänglich zu machen: Der Wolf hat die Großmutter nicht gelöscht – er hat sie gefressen.

CRUD (Create, Read, Update, Delete) ist das Standardvokabular der meisten Anwendungen. Aber es ist ein technisches Vokabular, kein fachliches. Es versteckt, was wirklich passiert. Es reduziert Geschäftsprozesse auf Datenbankoperationen. Und es macht Systeme zu schwarzen Löchern, in denen die Vergangenheit verschwindet.

Das Märchen hat offenbar einen Nerv getroffen. Vielleicht, weil jede Entwicklerin und jeder Entwickler schon einmal vor einem System stand und sich gefragt hat: „Wie ist dieser Datensatz eigentlich in diesen Zustand gekommen?“

Die konzeptionellen Grundlagen

Wenn CRUD das Problem ist, was ist dann die Lösung? Darauf habe ich in zwei Artikeln geantwortet: „Event Sourcing: Die bessere Art zu entwickeln?“ und „CQRS als Grundlage für moderne, flexible und skalierbare Anwendungsarchitektur“.

Event Sourcing bedeutet, nicht den Zustand zu speichern, sondern die Ereignisse, die zu diesem Zustand geführt haben. CQRS bedeutet, Lesen und Schreiben zu trennen, weil beide unterschiedliche Anforderungen haben. Zusammen bilden sie die Bausteine für Systeme, die Fachlichkeit ernst nehmen. Systeme, in denen man nachvollziehen kann, was passiert ist, und in denen man neue Fragen an alte Daten stellen kann.

Die Vertiefung

Konzepte sind das eine, Umsetzung das andere. Deshalb habe ich im Sommer eine siebenteilige Serie geschrieben: „Event-Driven“. Von den Grenzen klassischer Architekturen über die Bausteine Event-getriebener Systeme bis hin zur praktischen Umsetzung am Beispiel einer Stadtbibliothek.

Es war mein umfassendstes Werk zum Thema in diesem Jahr. Und es war mir wichtig zu zeigen, dass Event-getriebene Architektur kein akademisches Konzept ist, sondern ein praktikabler Weg, Software zu bauen, die die Sprache der Domäne spricht.

Technische Tiefe im Dienst der Fachlichkeit

Wer über Event Sourcing spricht, muss auch über Vertrauen sprechen. Wie kann ich beweisen, dass ein bestimmtes Ereignis zu einem bestimmten Zeitpunkt stattgefunden hat? Wie kann ich Nachvollziehbarkeit garantieren, ohne alle meine Daten offenlegen zu müssen?

In „Merkle-Trees: Datenintegrität kryptografisch beweisen“ habe ich gezeigt, wie sich diese Fragen elegant lösen lassen. Merkle-Trees sind keine neue Erfindung. Sie stecken in Git, in Blockchains, in Certificate-Transparency. Aber im Zusammenspiel mit Event Sourcing entfalten sie ihre volle Stärke: Sie machen Nachvollziehbarkeit nicht nur möglich, sondern beweisbar.

Das ist keine technische Spielerei. Das ist relevant für Compliance, für Audits, für die DSGVO. Technik im Dienst realer Anforderungen.

Heilige Kühe hinterfragen

Der letzte Artikel in dieser Reihe ist der jüngste und vielleicht der kontroverseste: „Wendet man DDD auf DDD an, bleibt kein Domain-Driven Design übrig“.

Domain-Driven Design ist in meiner Community so etwas wie eine heilige Kuh. Und ich schätze die Grundideen von DDD sehr. Aber ich beobachte auch, wie DDD selbst zur Selbstbeschäftigung wird. Wie Teams Bounded-Contexts definieren, ohne je mit einer Fachexpertin gesprochen zu haben. Wie Aggregate und Value-Objects zum Selbstzweck werden, statt der Domäne zu dienen.

Das ist keine Kritik an Eric Evans oder an DDD als Idee. Es ist eine Kritik daran, wie wir als Community manchmal Methoden über Ergebnisse stellen. Und es ist ein Plädoyer dafür, auch unsere liebsten Werkzeuge kritisch zu hinterfragen.

So viel ich auch schreibe, am Ende ist es die Community, die diese Themen lebendig macht. Und 2025 hat mir gezeigt, dass ich mit meinen Überzeugungen nicht allein bin.

Im Oktober waren mein Kollege Rendani und ich auf der KanDDDinsky in Berlin – erstmals als Sponsoren und Aussteller für EventSourcingDB. 250 bis 300 Menschen, die unsere Leidenschaft für Domain-Driven Design, Event-Sourcing und durchdachte Softwarearchitektur teilen. Die Gespräche dort haben mir gezeigt: Das Thema hat Momentum. Event-Sourcing und CQRS sind keine Nischeninteressen mehr, die von einer kleinen Gruppe Enthusiasten in isolierten Ecken praktiziert werden.

Besonders gefreut hat mich die Veröffentlichung von OpenCQRS 1.0 durch Digital Frontiers, ein CQRS- und Event-Sourcing-Framework für die JVM mit nativer EventSourcingDB-Integration. Es entsteht ein Ökosystem. Andere bauen auf dem Fundament auf. Das ist die schönste Bestätigung für die Arbeit, die man in ein Projekt steckt.

Und natürlich danke ich Ihnen, den Leserinnen und Lesern, die kommentiert, diskutiert, widersprochen haben. Gerade die kontroversen Artikel haben mir gezeigt, dass das Thema bewegt. Widerspruch ist kein Problem, Gleichgültigkeit wäre eines.

Ausblick: Fachlichkeit, Architektur und KI

Wenn ich auf 2026 blicke, sehe ich ein Thema, das alles andere überlagern wird: Künstliche Intelligenz. Aber nicht so, wie es oft diskutiert wird.

In meinem Blogpost „Event-Sourcing als perfekte Grundlage für KI“ habe ich argumentiert, dass die Diskussion um KI zu oft bei den Modellen beginnt. Welches LLM ist das beste? GPT oder Claude? Aber das ist die falsche Frage. Die richtige Frage lautet: „Welche Daten habe ich?“

Ein durchschnittliches Modell mit hochwertigen Daten wird jedes Spitzenmodell schlagen, das auf minderwertigen Daten trainiert wurde. Und die Daten der meisten Unternehmen sind minderwertig, weil sie in CRUD-Systemen liegen, die nur den aktuellen Zustand kennen. Die Vergangenheit? Überschrieben. Der Kontext? Verloren. Die Kausalität? Nicht rekonstruierbar.

Event Sourcing ändert das. Es liefert kontextreiche, nachvollziehbare Daten. Es beantwortet nicht nur die Frage „Was ist?“, sondern auch „Wie ist es dazu gekommen?“ Und genau das braucht KI.

Gleichzeitig verschiebt sich die Wertschöpfung in der Softwareentwicklung. In „KI macht Entwickler ersetzbar, aber gute Architekten nicht“ habe ich beschrieben, was das bedeutet: Codieren wird zur Commodity. Was bleibt, ist Domänenwissen, Architektur, Modellierung. Das ist kein Untergang für unseren Berufsstand, es ist vielmehr eine Chance für alle, die Fachlichkeit ernst nehmen.

Die Kombination aus Architektur, Fachlichkeit und KI wird in Zukunft immer wichtiger. Wer versteht, wie man Systeme baut, die gute Daten produzieren, wer versteht, wie man KI sinnvoll einsetzt, und wer gleichzeitig die Domäne versteht, für die er entwickelt, der wird gefragt sein. Genau an dieser Schnittstelle arbeite ich gerade an einer Webinar-Reihe für 2026: der tech:lounge 360°. Für alle, die nicht von KI überrollt werden wollen, sondern sie verstehen und nutzen möchten.

Zum Schluss

Softwareentwicklung ist kein Selbstzweck. Das war mein Leitsatz zu Beginn dieses Artikels, und es ist mein Leitsatz am Ende dieses Jahres.

2025 war für mich das Jahr, in dem dieser Satz Gestalt angenommen hat: in EventSourcingDB, in über 40 Blogposts, in Gesprächen auf Konferenzen, in der Arbeit mit Kundinnen und Kunden. Es war ein intensives Jahr, ein produktives Jahr, und ich bin dankbar für alle, die diesen Weg mitgegangen sind.

Ich wünsche Ihnen Zeit zwischen den Jahren. Zeit zum Nachdenken, was eigentlich das fachliche Problem ist, das Sie lösen wollen. Zeit, um innezuhalten und sich zu fragen, ob die Technik, mit der Sie arbeiten, der Fachlichkeit dient oder zum Selbstzweck geworden ist.

Und dann ein Jahr 2026, in dem die Technik wieder das wird, was sie sein sollte: ein Werkzeug im Dienst dieser Fachlichkeit.

Frohe Weihnachten, ruhige und erholsame Feiertage, und einen guten Start ins neue Jahr.

(rme)