Vor drei Jahren sitze ich bei einem Maschinenbauer in Ostwestfalen. 85 Mitarbeiter, solides ERP, und ein interner Entwickler, der gerade Event Sourcing in die neue Auftragsmanagement-Software eingebaut hat. Architektonisch sauber. Technisch beeindruckend. Jedes Statusupdate eines Fertigungsauftrags — unveränderlich, auditierbar, replay-fähig.
Das Problem: Die einzige Person, die das System verstand, war eben jener Entwickler. Der hat vier Monate später gekündigt. Was blieb, war ein Event-Store mit achtzehn verschiedenen Event-Typen, null Dokumentation, und einem Nachfolger, der mich fragte, ob man das nicht einfach durch eine normale Datenbank ersetzen könnte. Spoiler: Ja, man konnte. Und wir haben es gemacht.
Was Nick Chapsas sagt — und er hat Recht
Nick Chapsas legt das Konzept in seinem Artikel sauber offen: Statt den aktuellen Zustand einer Entität zu speichern, werden alle Zustandsänderungen als unveränderliche Events gespeichert. Der Zustand wird bei Bedarf durch Replay aller Events rekonstruiert. Er zeigt das an einem konkreten .NET-Beispiel — StudentCreated, StudentEnrolled, StudentUnEnrolled — und erklärt die zentralen Vorteile: vollständige Audit-History, Time Travel (den Zustand zu jedem beliebigen Zeitpunkt sehen), und die natürliche Kombination mit CQRS für separate Lese- und Schreibmodelle.
Der Artikel ist technisch korrekt und gut strukturiert. Wer .NET entwickelt und das Muster verstehen will, ist dort richtig. Was der Artikel nicht liefert — und das ist keine Kritik, das ist schlicht nicht sein Scope — ist die Frage, ob man das überhaupt einsetzen sollte. Und genau das ist die Frage, die mir im Mittelstand täglich gestellt wird.
Wie das im KMU-Kontext wirklich landet
Lass mich ehrlich sein: Event Sourcing ist eines der Muster, das ich in meiner Beratungspraxis am häufigsten rückgebaut habe. Nicht weil es falsch wäre, sondern weil es in den falschen Kontexten eingesetzt wurde.
Die Kosten, die niemand benennt
Ein Event-Store ist kein Drop-in-Ersatz für eine relationale Datenbank. Du musst Snapshots bauen, sobald deine Event-Streams lang werden — sonst dauert das Replay irgendwann Sekunden statt Millisekunden. Du brauchst Schema-Evolution für Events, weil sich Datenstrukturen ändern. Du brauchst Upcasters, wenn alte Events in neue Formate migriert werden müssen. Und du brauchst Entwickler, die all das verstehen und warten können.
In einem KMU mit einer Person im IT-Team oder einem externen Dienstleister, der einmal pro Quartal vorbeischaut, ist das kein akademisches Problem — das ist ein Risiko für die Betriebskontinuität.
Ein Richtwert aus meiner Praxis: Für eine typische KMU-Applikation mit 50.000 bis 500.000 Datensätzen erhöht Event Sourcing den initialen Entwicklungsaufwand um 40 bis 80 Prozent. Die laufenden Wartungskosten liegen dauerhaft 20 bis 30 Prozent höher als bei einem klassischen CRUD-Modell — wenn das Team das Muster wirklich beherrscht. Wenn nicht, multiplizierst du das mit 2.
Wann es sich trotzdem lohnt
Es gibt aber echte Fälle, in denen ich Event Sourcing im Mittelstand empfehle. Drei davon kommen mir regelmäßig unter:
Finanz- und Compliance-Systeme mit gesetzlicher Revisionspflicht. Wenn dein Steuerberater oder die Wirtschaftsprüfung eine lückenlose Änderungshistorie braucht — nicht als nettes Feature, sondern als gesetzliche Anforderung — dann ist Event Sourcing keine Architektur-Spielerei, sondern die direkteste Lösung. Ein Buchführungssystem, bei dem jede Buchung als unveränderliches Ereignis gespeichert wird, erfüllt GoBD-Anforderungen fast von Haus aus. Das spart echte Compliance-Stunden.
Workflows mit komplexen Zustandsübergängen. Fertigungsaufträge, die durch 15 Statuswechsel laufen und bei jedem Schritt andere Abteilungen informieren — das ist ein natürlicher Fit. Aber auch hier: nur dann, wenn die Zustandsübergänge wirklich komplex sind. Wenn du drei Zustände hast (Offen, In Bearbeitung, Abgeschlossen), reicht eine Status-Spalte und ein Timestamp.
Systeme, bei denen Debugging und Support mehr kosten als Entwicklung. Ich hatte einen Mandanten im Großhandel, bei dem Support-Tickets wie "warum hat das System automatisch Nachbestellungen ausgelöst?" im Schnitt zwei Stunden Analyse kosteten. Keine nachvollziehbare History, kein Audit-Log, nur ein aktueller Zustand. Dort hat Event Sourcing die Support-Kosten halbiert — weil man jeden Entscheidungsmoment nachvollziehen konnte. Das war der Business Case, nicht die Architektur-Eleganz.
Was im Artikel fehlt: die Einstiegsfrage
Nick Chapsas zeigt, wie man Event Sourcing implementiert. Die Frage, die ich in jedem Mandat zuerst stelle: Hast du heute ein konkretes Problem, das Event Sourcing besser löst als ein normales Audit-Log?
Ein Audit-Log — also eine separate Tabelle, die jeden Schreibvorgang mit Timestamp, User und altem sowie neuem Wert protokolliert — deckt 80 Prozent der Anforderungen ab, die mir KMU als Begründung für Event Sourcing nennen. Es ist einfacher zu implementieren, einfacher zu erklären, einfacher zu warten. Tools wie Entity Framework Interceptors oder Trigger auf Datenbankebene machen das in .NET ohne großen Aufwand.
Wenn du Time Travel brauchst oder komplexe Domain-Logik, bei der der Zustand erst aus Events rekonstruiert werden muss: dann sprich über Event Sourcing. Wenn du "nur" nachvollziehen willst, wer wann was geändert hat: nimm das Audit-Log.
Meine konkrete Empfehlung
Bevor du Event Sourcing einführst, beantworte diese drei Fragen ehrlich:
-
Gibt es eine Person in deinem Team, die das Muster vollständig versteht und in zwei Jahren noch da ist? Wenn die Antwort unsicher ist, ist das Muster zu riskant.
-
Hast du eine gesetzliche oder fachliche Anforderung, die ein Audit-Log nicht erfüllt? Wenn du die Anforderung nicht konkret benennen kannst, brauchst du Event Sourcing nicht.
-
Kannst du dir leisten, 40 Prozent mehr Entwicklungszeit für die erste Version einzurechnen? Wenn das Budget oder der Zeitplan knapp ist, gibt es günstigere Wege zur gleichen Funktionalität.
Zwei von drei Nein: Nimm das Audit-Log, spare die Energie, und investiere sie in Features, die deine Nutzer tatsächlich sehen.
Der vollständige Original-Beitrag von Nick Chapsas: Getting Started with Event Sourcing in .NET
Willst du wissen, ob Event Sourcing für dein konkretes Projekt der richtige Ansatz ist — oder ob du damit gerade eine Architekturentscheidung triffst, die dich in zwei Jahren bereust?
— Bernhard