NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Ereigniswürfel laufen in Container mit Schriftzug Event Sourcing

Event Sourcing: Definition und Einordnung

Event Sourcing speichert nicht den aktuellen Zustand, sondern jedes fachliche Ereignis, das dazu geführt hat. Der aktuelle Stand entsteht, indem alle Ereignisse eines Aggregats der Reihe nach angewendet werden.
Das Vorbild ist das Kontobuch. Eine Bank speichert keinen Kontostand und überschreibt ihn bei jeder Buchung, sie schreibt Buchungen fort. Der Stand ist das Ergebnis, nicht die Wahrheit. Genau dieses Prinzip überträgt Event Sourcing auf Software.
Der Ansatz wird häufig zusammen mit CQRS und Domain Driven Design genannt, funktioniert aber unabhängig davon. Er passt gut in einen Bounded Context, in dem die Historie selbst fachlich wertvoll ist, und schlecht als Grundlage für ein ganzes System.

Inhalt

Event Sourcing mit NCA: Schnelle Hilfe vom Experten

Event Sourcing ist mächtig und teuer zugleich. Never Code Alone begleitet Teams seit über zwanzig Jahren bei genau solchen Entscheidungen und sagt auch, wenn ein einfaches Änderungsprotokoll reicht. Unsere Basis ist täglicher Betrieb mit Symfony, Sulu CMS, PHPUnit und PHPStan.
Wird umgestellt, geschieht das abgesichert: Characterization Tests halten das heutige Verhalten fest, Parallel Run vergleicht alte und neue Ergebnisse im Betrieb, Parallel Change hält Schemawechsel bruchfrei. Für die Einordnung im KI gestützten Alltag steht Vibe Coding Consulting bereit.
Historie richtig modellieren mit NCA
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

So funktioniert Event Sourcing technisch

Die Bausteine sind überschaubar. Ein Event Store speichert Ereignisse in fester Reihenfolge, ein Aggregate baut daraus seinen Zustand auf, und Projektionen erzeugen Lesemodelle für die Oberfläche.
  • Event: eine Tatsache in der Vergangenheit, benannt in der Fachsprache. OrderCancelled, nicht OrderUpdate.
  • Event Store: eine Tabelle mit Aggregat, Version, Typ und Daten. Nur Einfügen, kein Ändern, kein Löschen.
  • Replay: alle Ereignisse eines Aggregats werden angewendet und ergeben den aktuellen Zustand.
  • Projektion: aus den Ereignissen entsteht eine Tabelle für Listen und Auswertungen.
  • Snapshot: ein Zwischenstand nach vielen Ereignissen, damit das Replay kurz bleibt.
Code: 
          
final class Order
{
    private OrderStatus $status;
    private array $pendingEvents = [];

    public static function fromHistory(Event ...$events): self
    {
        $order = new self();
        foreach ($events as $event) {
            $order->apply($event);
        }

        return $order;
    }

    public function cancel(CancellationReason $reason): void
    {
        if ($this->status === OrderStatus::Cancelled) {
            return;
        }

        $this->record(new OrderCancelled($reason));
    }
}
Auffällig ist, was fehlt: kein Setter, kein Statusfeld von außen. Der Zustand entsteht ausschließlich aus Ereignissen. Diese Strenge macht die Domäne sehr gut testbar, weil jeder Test aus einer Liste von Ereignissen und einer erwarteten Reaktion besteht.

Zustand speichern gegen Ereignisse speichern

Thema Klassische Speicherung Event Sourcing
Historie Geht beim Überschreiben verloren Vollständig vorhanden, inklusive Reihenfolge
Abfragen Direkt per SQL möglich Nur über Projektionen sinnvoll
Schemaänderung Migration der Tabelle Versionierte Ereignisse und Upcasting
Betrieb Vertraut, wenig Zusatzaufwand Projektionen überwachen und neu aufbauen können

Was Event Sourcing im Betrieb wirklich kostet

Der Aufwand steckt nicht im Schreiben der Ereignisse, sondern im Alltag danach. Drei Punkte unterschätzen Teams regelmäßig.
Ereignisse ändern sich: Ein Feld fehlt, ein Name passt nicht mehr. Alte Ereignisse lassen sich aber nicht nachträglich ändern. Stattdessen gibt es Versionen und eine Übersetzung beim Laden. Das muss von Anfang an eingeplant werden.
Projektionen brauchen Pflege: Jede neue Auswertung heißt neue Projektion, jeder Fehler heißt Neuaufbau aus dem Event Store. Dieser Neuaufbau muss geübt und automatisiert sein, sonst wird er im Ernstfall zum Abenteuer. Monitoring mit Sentry und Grafana gehört dazu.
Löschen wird schwierig: Ein unveränderlicher Speicher und das Recht auf Löschung passen nicht von selbst zusammen. Personenbezogene Daten gehören deshalb nicht roh in Ereignisse, sondern hinter eine Referenz, die gelöscht werden kann. Diese Frage klärt man vor der ersten Zeile Code, nicht im Audit.
Passt gut: Abrechnung, Buchhaltung, Logistik, alles mit Nachweispflicht oder fachlich wertvoller Historie. Passt schlecht: Stammdatenpflege, einfache Verwaltung, kleine Teams ohne Erfahrung mit asynchroner Verarbeitung.

Ereignisse als Gedächtnis für KI gestützte Arbeit

Ein Event Store beschreibt, was im Geschäft tatsächlich passiert ist, in der Sprache des Fachbereichs. Für Auswertungen ist das wertvoller als eine Tabelle mit dem letzten Stand, weil Reihenfolge und Ursache erhalten bleiben.
Für die Arbeit mit einem Coding Agent hat das einen praktischen Nebeneffekt: Ereignisnamen sind eine fertige Beschreibung der Domäne. Wer eine Liste wie OrderPlaced, PaymentRecorded, OrderCancelled sieht, versteht den Ablauf ohne Dokumentation. Menschen im Onboarding übrigens auch.
Die NCA Regel für Daten bleibt bestehen: Coding Modelle, die nicht auf eigener Infrastruktur laufen, arbeiten gegen lokale Entwicklungsumgebungen mit Testdaten, niemals gegen echte Ereignisse aus dem Produktivsystem. Ein Event Store enthält vollständige Geschäftsvorfälle, entsprechend sorgfältig wird er behandelt.

CQRS is not Event Sourcing.

Greg Young, Urheber des CQRS Begriffs – Greg Young's Blog

Die NCA Erfahrung mit Historie und Nachvollziehbarkeit

Sehr oft steckt hinter dem Wunsch nach Event Sourcing eine einfachere Anforderung: Jemand möchte nachvollziehen können, wer wann was geändert hat. Dafür reicht in vielen Fällen ein sauberes fachliches Änderungsprotokoll neben der bestehenden Struktur. Wir prüfen diese Frage zuerst, bevor ein Umbau beginnt.
Fällt die Entscheidung für Event Sourcing, wird abgesichert gearbeitet. Characterization Tests halten das heutige Verhalten fest, Symfony KernelTestCase prüft das Zusammenspiel, Infection zeigt, ob die Tests wirklich greifen. Der Vergleich im Betrieb läuft über Parallel Run.
Die fachliche Grundlage bleibt entscheidend: Ereignisnamen sind nur so gut wie die Ubiquitous Language dahinter. Wo Ereignisse Bereichsgrenzen überschreiten, hilft eine Karte aus dem Context Mapping und an fremden Systemen ein Anti Corruption Layer. Weitere Werkzeuge stehen im NCA PHP Glossar.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zu Event Sourcing

Die Fragen, die vor einer Entscheidung für oder gegen Event Sourcing geklärt gehören.

Was ist Event Sourcing 2026 einfach erklärt?

Event Sourcing speichert nicht den aktuellen Zustand, sondern jedes fachliche Ereignis, das dazu geführt hat. Der aktuelle Stand entsteht, indem alle Ereignisse eines Aggregats der Reihe nach angewendet werden. Das Vorbild ist das Kontobuch: Buchungen werden fortgeschrieben, der Saldo ist das Ergebnis und nicht die gespeicherte Wahrheit.

Braucht Event Sourcing 2026 zwingend CQRS?

In der Praxis fast immer. Ein Event Store lässt sich nicht sinnvoll für Listen und Auswertungen abfragen, dafür braucht es Projektionen als Lesemodelle. Das ist bereits CQRS. Umgekehrt gilt das nicht: CQRS funktioniert problemlos mit einer klassischen Datenbank und ganz ohne Event Sourcing.

Wann lohnt sich Event Sourcing 2026?

Wenn die Historie selbst fachlich wertvoll ist. Typisch sind Abrechnung, Buchhaltung, Logistik und alles mit Nachweispflicht. Auch Domänen, in denen die Frage warum ist dieser Zustand entstanden regelmäßig gestellt wird, profitieren. Für Stammdatenpflege und einfache Verwaltung ist der Aufwand nicht gerechtfertigt.

Wie geht Event Sourcing 2026 mit der DSGVO zusammen?

Mit Planung. Ein unveränderlicher Speicher und das Recht auf Löschung passen nicht von selbst zusammen. Übliche Lösung ist, personenbezogene Daten nicht roh in Ereignisse zu schreiben, sondern hinter eine Referenz zu legen, die gelöscht werden kann. Diese Frage gehört vor die erste Zeile Code.

Was ändert sich 2026 durch KI gestützte Entwicklung?

Vor allem die Lesbarkeit der Domäne. Ereignisnamen wie BestellungAufgegeben oder ZahlungErfasst beschreiben den Ablauf ohne Dokumentation, was Menschen beim Onboarding und Agents beim Verstehen hilft. An der Datenregel ändert sich nichts: Modelle arbeiten gegen lokale Umgebungen mit Testdaten, nie gegen echte Ereignisse.

Wie ändert man ein Ereignis nachträglich?

Gar nicht. Ereignisse sind Tatsachen der Vergangenheit und bleiben unverändert. Ändert sich die Struktur, entsteht eine neue Version des Ereignisses, und beim Laden übersetzt ein Upcaster die alte Form in die neue. Wer das nicht von Anfang an einplant, steht beim ersten Feldwechsel vor einem Problem.

Was ist eine Projektion?

Eine Projektion liest Ereignisse und schreibt daraus eine Tabelle für Listen und Auswertungen. Sie ist bewusst wegwerfbar: Bei einem Fehler wird sie gelöscht und aus dem Event Store neu aufgebaut. Genau dieser Neuaufbau sollte automatisiert und geübt sein, bevor er im Ernstfall gebraucht wird.

Wozu dienen Snapshots?

Sie verkürzen das Replay. Hat ein Aggregat tausende Ereignisse, dauert der Aufbau aus der vollständigen Historie zu lange. Ein Snapshot speichert den Zustand nach einer bestimmten Version, danach werden nur noch die neueren Ereignisse angewendet. Nötig wird das erst bei wirklich langen Historien.

Welchen Speicher nimmt man in PHP?

Für die meisten Projekte reicht eine relationale Datenbank mit einer Ereignistabelle aus Aggregat, Version, Typ und Daten, plus einem eindeutigen Index auf Aggregat und Version. Spezialisierte Event Stores lohnen sich erst bei hohem Durchsatz. MySQL oder PostgreSQL tragen deutlich weiter, als viele erwarten.

Wie testet man eine Domäne mit Event Sourcing?

Sehr angenehm. Ein Test besteht aus einer Liste vergangener Ereignisse, einer ausgelösten Absicht und den erwarteten neuen Ereignissen. Keine Datenbank, keine Mocks, nur Fachlichkeit. Diese Tests lassen sich einem Fachexperten vorlesen und sind mit PHPUnit schnell geschrieben.

Lässt sich Event Sourcing nachträglich einführen?

Nur bereichsweise und mit Vorarbeit. Sinnvoll ist ein einzelnes Aggregat mit hohem fachlichem Wert, abgesichert durch Tests und im Betrieb mit Parallel Run gegen die bestehende Logik verglichen. Eine Umstellung des ganzen Systems auf einmal ist in gewachsenen Anwendungen kein realistischer Plan.

Wie berät NCA zu dieser Entscheidung?

Wir klären zuerst die eigentliche Anforderung. Oft geht es um Nachvollziehbarkeit, und dafür reicht ein fachliches Änderungsprotokoll. Ist Event Sourcing der richtige Weg, bauen wir es abgesichert und bereichsweise um. Jede Zusammenarbeit startet mit einem kostenlosen Kennenlernen, danach schätzen wir den Aufwand ein und rechnen transparent minutengenau ab.