Warum CRUD für Märchen und Unternehmen gleichermaßen ungeeignet ist

Es war einmal … eine wunderschöne Prinzessin. Jedes Jahr updatete sie ihr Alter, und nach einigen Jahren createte sie den Wunsch, die Welt zu entdecken, und updatete ihre Position in den großen, dunklen Wald. Dort createte jedoch der böse Wolf ein Meeting mit ihr und deletete sie. Das Königspaar updatete seinen Gemütszustand daraufhin auf „traurig“ und createte einen Auftrag für den Jäger. Dieser updatete seine Position ebenfalls in den großen, dunklen Wald, createte ein Meeting mit dem Wolf, deletete ihn – und wollte anschließend die Prinzessin undeleten – aber in CRUD-basierten Systemen gibt es kein Undelete.

Das heißt, stattdessen müsste man die Geschichte neu erzählen und sie nun aber derart ändern, dass der Wolf die Prinzessin nicht mehr deletet, sondern ihr isDeleted-Flag auf true aktualisiert. Zugegebenermaßen wird das Märchen damit aber nicht besser: Es ist jetzt schon absurd, klingt reichlich merkwürdig und eignet sich vermutlich eher dazu, Menschen zu verstören, als ihnen eine spannende Geschichte zu erzählen.

Warum das Märchen so merkwürdig klingt

Diese bewusst überspitzte Kurzfassung ist allerdings weit mehr als ein Gag. Denn sie macht erfahrbar, was in vielen Softwareprojekten tagtäglich passiert: Fachsprache und technische Sprache laufen auseinander. In der Domäne geschehen konkrete Dinge mit Bedeutung – der Wolf frisst die Prinzessin, der Jäger rettet sie –, während unsere Systeme dieselben Vorgänge auf die vier technischen Grundoperationen Create, Read, Update und Delete (kurz CRUD) reduzieren. Fachlich relevante Verben verschwinden hinter generischen Bearbeitungsschritten.

Dieses Auseinanderlaufen hat aber weitreichende Folgen:

• Verlust an Bedeutung: Ein Update sagt nichts darüber aus, welche fachliche Änderung eingetreten ist, geschweige denn, warum das passiert ist. Wurde ein Vertrag verlängert oder ein Konto gesperrt? Wurde eine Zahlung zurückgebucht oder ein Limit angepasst? Fachabteilungen erkennen ihre Welt in der CRUD-Sprache nicht wieder.
• Verlust an Historie: Das Überschreiben von Zuständen verwischt Spuren. Wie ist ein Zustand entstanden? Welche Abfolge führte zu einem Fehler oder zu einem Erfolg? Audits, Ursachenanalysen und Prognosen leiden, wenn die Vergangenheit nicht explizit dokumentiert ist.
• Fehlkonzepte und Workarounds: Wo Delete fachlich nicht zulässig ist, entstehen Soft-Deletes mit isDeleted-Flags. Wo Korrekturen nötig sind, wird ein Undelete herbeifantasiert – oder es entstehen Spezialpfade, die die Semantik weiter verwässern.
• Kommunikationsbruch zwischen Fachseite und IT: Wenn Entwicklerinnen und Entwickler über Updates sprechen, während Fachanwenderinnen und Fachanwender über Kündigungen, Rückgaben oder Eskalationen reden, steigt die Wahrscheinlichkeit von Missverständnissen – und damit von Fehlentscheidungen.

Kurz: CRUD ist eine technische Abstraktion, die fachliche Realität unsichtbar macht. Sie ist bequem für Tabellen, aber sie ist arm an Bedeutung.

Ein anderer Blick: Ereignisse statt bloßer Zustandsänderungen

Hier setzt Event-Sourcing an, ein alternatives Konzept zur Persistenz von Daten. Statt stets den aktuellen Zustand zu speichern und ihn regelmäßig per Update zu überschreiben, erfasst Event-Sourcing die Ereignisse, die im Laufe der Zeit zu diesem Zustand geführt haben – und zwar in der Sprache der Fachdomäne.

Im Märchen wären es Ereignisse wie: „Prinzessin betrat Wald“, „Wolf traf Prinzessin“, „Wolf fraß Prinzessin“, „Jäger hat Wolf getötet“, „Prinzessin wurde befreit“, und so weiter. Jedes Ereignis ist dabei ein unveränderlicher Fakt und bleibt dauerhaft erhalten. Der aktuelle Zustand (wie zum Beispiel, dass die Prinzessin noch beziehungsweise wieder lebt oder dass sie von ihren Eltern vermisst wird) ergibt sich als Projektion aus der Abfolge dieser Fakten.

Diese Sichtweise bringt handfeste Vorteile:

• Transparenz und Nachvollziehbarkeit: Jede Änderung ist datums- und ursachengenau belegbar. Sie können Point-in-Time prüfen, warum ein System heute so ist, wie es ist.
• Saubere Semantik: Ereignisse tragen fachliche Bedeutung. Statt generischer Updates sehen Sie Vertragsverlängerungen, Stornos, Rollentausche, Zahlungseingänge – exakt die Begriffe, in denen Fachabteilungen denken und sprechen.
• Korrekturen ohne Geschichtsfälschung: Fehler werden nicht durch rückwirkende Manipulation „unsichtbar“ gemacht, sondern durch kompensierende Ereignisse korrigiert. So bleibt die Datenlinie integer.
• Bessere Analysen: Ereignisströme bilden Verhalten über die Zeit ab. Das ist die Grundlage für Ablaufanalysen, Anomalieerkennung und Vorhersagen – und damit eine tragfähige Basis für Anwendungen im Bereich künstlicher Intelligenz.
• Entkopplung und Evolution: Ereignisse sind hervorragende Integrationspunkte. Weitere Systeme können sich andocken, ohne den Kern zu stören – ein zentraler Baustein moderner, vernetzter Architekturen.

Mehr Details, wie man mit diesem Ansatz Software entwerfen und entwickeln kann, finden Sie auf cqrs.com. Wenn Sie sich speziell für das Zusammenspiel mit Künstlicher Intelligenz interessieren – von der Ereignisaufnahme über Projektionen bis hin zu Features für Machine-Learning-Modelle, dann sei Ihnen eventsourcing.ai zur Lektüre empfohlen.

Warum wir trotz allem an CRUD festhalten

Dass CRUD trotz alledem so verbreitet ist, hat weniger mit fachlicher Eignung zu tun als mit Gewöhnung und Werkzeughistorie. Relationale Datenbanken, OR-Mapper und viele Frameworks begünstigen eine Sicht primär auf den Status quo. Sie ist für einfache Datenerfassung ausreichend und kurzfristig effizient. Mit wachsender Komplexität – mehrere Prozesse, Querverbindungen, regulatorische Anforderungen, analytische Nutzung – kippt der Vorteil jedoch: Die Semantik verschwindet im Code, und das System wird schwer zu erklären, zu prüfen und zu verändern.

Die Märchenanalogie bringt genau das auf den Punkt: Wir zwingen eine fachliche Geschichte in vier technische Verben – und verlieren dabei die eigentliche Geschichte. In realen Systemen passiert tatsächlich dasselbe, nur subtiler. Aus „Kunde widerruft Bestellung“ wird ein Update, aus „Rolle wird delegiert“ wird ein Update, aus „Risiko wird neu bewertet“ wird ein Update. Am Ende bleibt ein Zustand – aber das Wissen, wie und warum er entstanden ist, geht verloren.

Event-Sourcing auf dem Software Architecture Gathering

Wenn Sie die vollständige Argumentation, konkrete Muster und praktische Umsetzungshinweise sehen möchten, lade ich Sie herzlich zum Software Architecture Gathering des iSAQB ein. Dort erkläre ich in meinem Vortrag „… and Then the Wolf DELETED Grandma“ im Detail, warum CRUD für Märchen wie für Unternehmen gleichermaßen ungeeignet ist, wo genau die Reibungsverluste entstehen und vor allem, wie Event-Sourcing diese Brüche auflöst. Es geht um Sprache, Modelle und Architektur – und darum, wie Sie Systeme gestalten, die sowohl für Fachanwender als auch für Entwicklerinnen erklärbar, prüfbar und erweiterbar bleiben.

Dabei bespreche ich typische Einwände („Ist das nicht zu aufwendig?“, „Wie migrieren wir?“, „Wie liest man effizient?“, …), zeige, warum Projektionen keine Notlösung, sondern ein Gestaltungsmittel sind, und warum Ereignisse eine robuste Grundlage für Analytik und KI bilden. Das Märchen bleibt als Leitmotiv erhalten – die fachlichen Konsequenzen stehen im Mittelpunkt.

Ich würde mich freuen, Sie in Berlin auf dem Software Architecture Gathering persönlich zu treffen – und gemeinsam zu diskutieren, wie wir Geschichten in Software endlich wieder mit den richtigen Verben erzählen können.

(rme)