UserDeleted, Diagnose Mord: Wenn Software wie ein Tatort klingt
Die Sprache, in der wir Prozesse beschreiben, entscheidet darüber, ob ein Softwaresystem Geschichten erzählt oder Polizeiberichte.
(Bild: stockwerk-fotodesign/Shutterstock.com)
- Golo Roden
Wenn ich Kunden zu Domain-Driven Design (DDD) und Event Sourcing berate, gibt es einen Moment, der regelmäßig eintritt. Das Team wirkt selbstbewusst, vielleicht sogar ein wenig stolz. Sie sagen mir:
„Eigentlich arbeiten wir schon mit Events."
Und dann zeigen sie mir ihre Events:
UserCreatedOrderUpdatedInvoiceDeleted
Und innerlich zucke ich zusammen.
Denn das sind keine Events, sondern klassisches CRUD, nur eben mit Event-Syntax. Es hat die äußerliche Form von Events, aber keine innerliche Semantik. Und dieser Unterschied, so subtil er auch erscheinen mag, ist der Unterschied zwischen einem System, das die Sprache des Business spricht, und einem, das die Sprache von Datenbanken spricht.
Das Beispiel: Enterprise-Print-Management
Stellen wir uns einen Kunden vor, der sich mit Enterprise-Drucken beschäftigt. Die Software verwaltet Tausende von Druckern in großen Organisationen: in Krankenhäusern, Universitäten und Unternehmensbüros. Drucker müssen dem System hinzugefügt, für Wartungsarbeiten offline genommen, pausiert, fortgesetzt und schließlich entfernt werden, wenn sie außer Betrieb genommen werden.
Das Team hat etwas gebaut, das sie ein „Event-getriebenes System“ nennen. Und das sind ihre Events:
PrinterCreatedPrinterUpdatedPrinterDeleted
Das war's. Drei Events. Kommt Ihnen das bekannt vor?
Das ist CRUD in Verkleidung. Die Namen haben sich von INSERT, UPDATE und DELETE zu Created, Updated und Deleted geändert, aber die semantische Armut ist dieselbe. Wenn man sich ein PrinterUpdated-Event ansieht, was weiß man dann? Irgendetwas hat sich geändert. Aber was genau hat sich geändert? Dazu muss man in den Payload schauen. Warum hat es sich geändert? Keine Ahnung. War es eine geplante Wartungsmaßnahme oder ein unerwarteter Ausfall? Das Event verrät es nicht.
Das Mordproblem
Und mich erinnert das immer an ein etwas düsteres Beispiel (und die Ironie ist hoffentlich offensichtlich): Betrachten wir UserDeleted (was mir in der Praxis auch regelmäßig begegnet).
Sprechen Sie das mal laut und bewusst aus: UserDeleted. Es klingt, als hätte man die Nutzerin oder den Nutzer erfolgreich ermordet:
„Der Nutzer wurde eliminiert.“
Wäre das ein Krimi, würden die Ermittlerinnen und Ermittler sich jetzt Notizen machen.
Aber was wahrscheinlich gemeint war: AccountClosed. Oder UserDeactivated. Oder SubscriptionCancelled. Jedes davon hat eine andere Bedeutung, andere geschäftliche Implikationen, andere nachgelagerte Effekte. Aber CRUD-Sprache presst all diesen Reichtum in ein einziges, leicht morbides Verb.
Das ist nicht nur unpräzise. Es ist aktiv irreführend. CRUD-Sprache verliert nicht nur Information. Sie kann Events wie einen Polizeibericht klingen lassen.
Es fehlt die Wartungsfrage
ZurĂĽck zu unseren Druckern. Eine Wartungstechnikerin ruft beim Helpdesk an:
„Dieser Drucker im dritten Stock funktioniert nicht. Was ist passiert?"
Der Support-Mitarbeiter schaut auf den aktuellen Zustand in der Datenbank:
{ "printerId": "printer-3f-01",
"status": "offline"
}
Das ist alles, was er sieht. Der Drucker ist offline. Aber warum? Wann ging er offline? Wurde er manuell fĂĽr Wartungsarbeiten offline genommen, oder ist er unerwartet ausgefallen? Ist das schon einmal passiert? Wie oft?
Mit CRUD-Events muss der Mitarbeiter nun Logs durchforsten, Zeitstempel korrelieren, vielleicht die Technikerin später zurückrufen. Jede Minute, die mit Nachforschungen verbracht wird, bedeutet verlorenes Geld und wachsende Frustration.
Das sind die versteckten Kosten semantischer Armut: Nicht nur verlorene Information, sondern verlorene Zeit, verlorener Kontext, verlorenes Vertrauen in das System.
Die semantische Alternative
Wie würden echte Events aussehen? Events, die erfassen, was tatsächlich passiert ist? In der Sprache der Domäne?
PrinterAddedPrinterBecameOnlinePrinterPausedPrinterResumedPrinterWentOfflinePrinterRemoved
Beachten Sie die subtile, aber wichtige Verschiebung. Es heißt PrinterAdded, nicht PrinterCreated. Warum? Weil der Drucker in keinem sinnvollen Weg „erstellt“ wurde. Niemand hat einen Drucker hergestellt, indem eine Datenbankzeile eingefügt wurde. Der Drucker existierte bereits. Er war ein physisches Objekt, das in einem Karton lag, aus einer Fabrik geliefert. Was passiert ist: Er wurde dem System lediglich hinzugefügt.
Created ist CRUD-Sprache. Added ist Domänensprache. Der Unterschied zählt.
Genauso Removed statt Deleted: Der Drucker wurde nicht zerstört. Er steht wahrscheinlich irgendwo in einem Lagerraum und wartet darauf, neu zugewiesen zu werden. Er wurde aus der Verwaltung dieses Systems entfernt. Das ist passiert. Das sollte das Event sagen.
Die vollständige Historie
Spielen wir nun den Support-Anruf mit echten Events durch. Der Mitarbeiter ruft die Historie des Druckers auf:
2026-01-15 09:00 PrinterAdded
2026-01-15 09:05 PrinterBecameOnline
2026-01-16 14:30 PrinterPaused { "reason": "scheduled maintenance" }
2026-01-16 16:00 PrinterResumed
2026-01-17 11:45 PrinterWentOffline { "reason": "paper jam detected" }
2026-01-17 12:00 PrinterBecameOnline
2026-01-18 09:22 PrinterWentOffline { "reason": "connection lost" }
Jetzt kann er alles sehen:
- Der Drucker ging heute um 09:22 Uhr offline, weil die Verbindung verloren ging.
- Das ist das zweite unerwartete Offline-Event in zwei Tagen.
- Gestern war es ein Papierstau, heute ist es Konnektivität.
- Davor gab es eine geplante Wartungspause, die reibungslos verlief.
Die Technikerin muss in Konsequenz also nicht blind herumprobieren. Sie weiĂź, dass sie die Netzwerkverbindung prĂĽfen muss, nicht das Papierfach. Sie kann ein Muster erkennen, weil das gleiche Problem in der Vergangenheit schon mit anderen Druckern aufgetreten ist: vielleicht versagt gerade die Netzwerkkarte dieses Druckers.
Das ist der Wert, den CRUD-Events nicht liefern können. Nicht nur „was ist der Zustand“, sondern „wie ist er dorthin gekommen“ und „was sagt uns dieses Muster“.
Events als natĂĽrliche Sprache
Das berührt etwas Grundlegenderes. In einem früheren Beitrag habe ich darüber geschrieben, wie niemand Geschichten mit CRUD erzählt. Man sagt nicht „Rotkäppchen wurde erstellt, dann aktualisiert, dann wurde die Großmutter gelöscht.“ Das ist absurd. Man erzählt die Geschichte durch Events: was passiert ist, in welcher Reihenfolge und warum es wichtig war.
Und in einem anderen Beitrag über DDD habe ich argumentiert, dass Domain-Driven Design unnötig kompliziert gemacht wurde. Die Essenz ist einfach: „Sprich die Sprache der Domäne!“ Aber wir haben diese Einfachheit unter Schichten von Patterns und Jargon begraben.
Hier ist der Zusammenhang: Wer gute Events formuliert, spricht automatisch die Sprache der Domäne. Man kann nicht PrinterPaused schreiben, ohne zu verstehen, dass Pausieren ein Konzept in dieser Domäne ist, unterschieden vom Offline-Gehen, unterschieden vom Entfernen. Der Akt des Benennens von Events zwingt dazu, Gespräche mit Domänenexpertinnen und -experten zu führen. „Wie nennen Sie es, wenn ein Drucker vorübergehend, aber absichtlich aufhört zu arbeiten?“ Diese Frage führt direkt ins Herz der Domäne.
Das ist DDD, ohne es DDD zu nennen. Keine Aggregates, keine Bounded-Contexts, keine einschĂĽchternde Terminologie. Nur Events, die erfassen, was passiert, benannt so, wie das Business sie benennt.
Der Weg zu DDD fĂĽhrt durch Events
Das heiĂźt mit anderen Worten: Event Sourcing ist ein Katalysator fĂĽr Domain-Driven Design.
Kundinnen und Kunden DDD zu erklären ist schwer. Die Terminologie schüchtert ein. Die Konzepte sind abstrakt. Viele Entwicklerinnen und Entwickler (mich eingeschlossen) haben sich irgendwann „zu dumm“ für DDD gefühlt, erschlagen von der Theorie.
Aber Events zu erklären ist einfach. Jede und jeder versteht Events. „Was ist passiert?“ ist eine Frage, die Menschen stellen, seit es Sprache gibt. Und wenn man Teams dazu bringt, ihre Events präzise zu benennen, machen sie am Ende ganz natürlich DDD. Sie beginnen, die Sprache der Domäne zu sprechen. Sie beginnen, Gespräche mit Domänenexpertinnen und -experten zu führen. Sie beginnen, Systeme zu bauen, die die Realität widerspiegeln, statt Datenbanktabellen.
Wer also auf die eigenen Events schaut und überall Created, Updated und Deleted sieht, hat die Chance, nicht nur das Event-Modell zu verbessern, sondern ein Gespräch darüber zu beginnen, was im eigenen Business tatsächlich passiert. Wie nennt man es, wenn ein Drucker hinzugefügt wird? Wenn eine Nutzerin oder ein Nutzer geht? Wenn eine Bestellung storniert versus erstattet versus angefochten wird?
Die Antworten auf diese Fragen verraten mehr über die Domäne als jeder Musterkatalog es je könnte.
Wie es weitergehen kann
Wenn Ihnen das bekannt vorkommt, fangen Sie hier an: Schauen Sie sich Ihre Events an! Lesen Sie sie laut vor! Klingen sie wie Datenbankoperationen, oder klingen sie wie Dinge, die in Ihrem Business passieren?
Für einen tieferen Einblick in die Konzepte hinter DDD und Event-Sourcing erklären diese Einführungen in Domain-Driven Design und Event-Sourcing die Grundlagen.
Denn Events sollten eine Geschichte erzählen, keinen Polizeibericht.
(rme)
