Event Sourcing: Hör auf, Geschichte zu verlieren, und nutz sie
Event Sourcing: was es ist (und nein, es ist nicht nur Logging)
Bei Event Sourcing sind Ereignisse die Quelle der Wahrheit. Du speicherst nicht den „Endzustand“ eines Objekts, du speicherst alles, was ihm passiert. Danach baust du den Zustand durch Replay der Ereignisse wieder auf. Ja, wie ein Replay. Und nein, es sind nicht „nur Logs“: Ein Log erzählt, ein Event gilt.
Beispiel: Statt balance = 120 zu speichern, protokollierst du MoneyDeposited(200) und danach MoneyWithdrawn(80). Der Kontostand ist ein Ergebnis, kein magischer Wert aus dem Nichts.
Warum solltest du dir das antun?
Weil dein Zukunfts-Ich dankbar ist, wenn:
- du auditieren musst, wer was, wann und warum gemacht hat,
- du debuggen willst, indem du die Realität nachspielst,
- du ein Modell nach Business-Änderungen rekonstruieren musst,
- du Projektionen (Read Models) willst, ohne die Datenbank zu schreddern.
Kurz: Du zahlst jetzt etwas Komplexität, damit du später keine Post-Mortems improvisierst.
Die Bausteine (ohne Rauch)
- Event: eine unveränderliche Tatsache in der Vergangenheit.
OrderPlaced, nichtPlaceOrder. - Stream: die Ereignisfolge eines Aggregats.
- Aggregat: das Domain-Objekt, das Events anwendet, um den Zustand aufzubauen.
- Projektion: eine abgeleitete Sicht (SQL, Elastic, Cache, etc.) für schnelle Reads.
Wann einsetzen (und wann lieber nicht)
Nutze es, wenn:
- dein Domänenmodell sich häufig ändert,
- Historie kritisch ist,
- du knallharte Nachvollziehbarkeit brauchst.
Lass es, wenn:
- dein CRUD banal ist,
- du keine Audits brauchst,
- dein Team gerade erst Repositories entdeckt.
Kleines Symfony-Einstiegsbeispiel
Wir halten es simpel: ein Cart-Aggregat, Events und ein In-Memory-Event-Store. Kein volles CQRS, kein Kafka, keine Zauberei. Nur der Kern.
1) Event definieren
php
2) Aggregat, das Events abspielt
php
3) Minimaler In-Memory-Event-Store
php
4) Nutzung in einem Symfony-Service
php
Fertig. Kein ORM, kein Cache, kein Umzug. Nur die zentrale Idee: Events sind die Wahrheit, der Zustand ist eine berechnete Sicht. Später kannst du Projektionen und Symfony-Messenger-Listener anhängen, wenn du mit den Großen spielen willst.
Merke (falls du's erklären musst)
- Event Sourcing speichert Historie, nicht nur Resultate.
- Du rekonstruierst den Zustand durch Replay der Events.
- Perfekt für Audit und sich ändernde Domänen, unnötig für langweiliges CRUD.
- Symfony macht's nicht für dich, lässt dich aber sauber strukturieren.
Wenn dir das schwer vorkommt: gut so. Du tauschst kurzfristigen Komfort gegen langfristige Klarheit. Du zahlst jetzt oder Zukunfts-Ich später. Deine Wahl.