Event Sourcing - Kernkonzepte

Einführung in das Event Sourcing

Zu Beginn (0:00) erörtert Derek die Verwirrung um Event Sourcing und die damit verbundenen Kernkonzepte. Er definiert Event Sourcing nicht nur als "Erfassen des aktuellen Zustands", sondern als Speichern von Ereignissen - Erfassen jeder Änderung, die an Ihrem Domänenmodell vorgenommen wird, in einem reinen Anhängeprotokoll.

Auf diese Weise erhalten Sie eine vollständige Historie der Statusänderungen Ihres Systems. Anstatt nur den Endzustand zu persistieren, persistieren Sie Ereignisse, die die aufgetretene Geschäftslogik widerspiegeln.

Ereignisse: Erfassen von Geschäftsfakten

Bei 0:33 erklärt Derek, was ein Ereignis wirklich ist. Ein Ereignis stellt etwas dar, das innerhalb des Systems bereits stattgefunden hat - eine geschäftliche Tatsache. Ein "ProductReceived"-Ereignis würde zum Beispiel die erhaltene Menge und das Datum enthalten.

Derek betont, dass beim Speichern von Ereignissen eine Namenskonvention verwendet werden muss, die die Vergangenheitsform widerspiegelt, wie z. B. "Produkt versandt" oder "Bestand angepasst". In einem Ereignisschema können Sie Felder wie public Guid Id, public string Name und Zeitstempel haben.

Jedes Ereignis sollte außerdem einen eindeutigen Bezeichner haben, was für ein reines Speichersystem, bei dem Ereignisse an einen Ereignisstrom angehängt werden, entscheidend ist.

Ereignisströme: Ereignisse organisieren

Bei 2:02 geht Derek zu den Ereignisströmen über. Er zieht einen Vergleich mit einer relationalen Datenbanktabelle, erklärt aber, dass beim Event Sourcing alle Ereignisse, die sich auf ein Domänenobjekt (z. B. ein Inventarobjekt) beziehen, zum selben Ereignisstrom gehören.

Jeder Ereignisstrom ist mit einer bestimmten Entität verknüpft, die oft durch eine öffentliche Guid Id und einen String Name definiert ist. Ein Produkt mit der Artikelnummer ABC123 hätte beispielsweise einen eigenen Stream mit persistierten Ereignissen wie Eingang oder Versand.

Derek schlägt vor, bei der Modellierung dieser Tools in Anlehnung an domänenorientierte Designkonzepte in Form von Aggregatwurzeln und Domänenobjekten zu denken.

Die Modellierung des Lebenszyklus - ob kurzlebig oder langlebig - hilft bei der Optimierung der Anzahl und Größe der Streams. Dies ist entscheidend für die Verbesserung der Leistung in komplexen Systemen.

Projektionen und Lesemodelle

Bei 4:12 stellt Derek Projektionen und das Lesemodell vor. Da Ihr ereignisgesteuertes System Ereignisse und nicht nur den aktuellen Zustand erfasst, müssen Sie Ereignisse wiedergeben, um Fragen wie "Wie hoch ist der aktuelle Lagerbestand?" zu beantworten

Um Lesemodelle zu erstellen, verarbeiten Sie Ereignisse aus dem Stream. Mit private void Apply(Event e) oder ähnlichem erhöhen oder verringern Sie beispielsweise den Bestand auf der Grundlage von Event-Handlern für jeden Ereignistyp.

Derek veranschaulicht, wie man ein Lesemodell in einer Dokumentendatenbank oder einer relationalen Datenbank erstellt - vielleicht zeigt eine Projektion einfach den Lagerbestand, eine andere die Versandhistorie.

Dies spiegelt die Command Query Responsibility Segregation (CQRS) wider: die Trennung der Schreiboperationen (Befehle) von den Leseoperationen (Abfragen).

Projektionen für Schreibmodelle

Bei 6:48 zeigt Derek, wie man Projektionen auch auf der Schreibseite anwenden kann. Dies ist entscheidend für die Validierung von Aktionen, bevor sie zugelassen werden.

In einem Command Handler muss vor dem Versand von Produkten überprüft werden, ob eine ausreichende Menge vorhanden ist. Derek verwendet eine Methode wie private void Apply(List events), um den erforderlichen Zustand wiederherzustellen.

Felder wie public int Version helfen dabei, die Entwicklung des Streams zu verfolgen, um die Konsistenz zu gewährleisten.

Diese praktische Implementierung hilft bei der Durchsetzung der Geschäftslogik bei der Behandlung neuer Ereignisse und stellt sicher, dass Ihr System nur auf gültige Zustandsübergänge reagiert.

Abonnements: Reagieren auf neue Ereignisse

Bei 8:01 spricht Derek über Abonnements. Mit Abonnements können Ereignisverbraucher auf neue Ereignisse warten und darauf reagieren.

Ein Projektor könnte zum Beispiel einen Ereignisstrom abonnieren und ein Lesemodell aktualisieren, wenn er ein Ereignis "Produkt versandt" sieht. Alternativ kann ein Publisher auf Ereignisse warten und diese an externe Systeme wie RabbitMQ oder Kafka weiterleiten und mit anderen Diensten verknüpfen.

Derek beschreibt Abonnements nicht nur für die Aktualisierung interner Modelle, sondern auch für die Verteilung von Daten über verschiedene Ereignissysteme hinweg, um die Konsistenz zu wahren.

Hier zeigt sich ein weiterer großer Vorteil der ereignisgesteuerten Architektur: Ihre Dienste bleiben letztendlich konsistent, aber unabhängig skalierbar.

Zusammenfassung der Kernkonzepte

Bei 9:21 fasst Derek die wichtigsten Konzepte zusammen:

• Ereignisse erfassen Fakten.

• Ereignisströme organisieren Ereignisse nach Entität.

• Projektionen verwandeln Datenströme in abfragbare Lesemodelle oder umsetzbare Schreibmodelle.

• Abonnements ermöglichen es den Diensten, entsprechend zu reagieren und zu aktualisieren.

Er hebt hervor, dass Sie Ereignisse in einem Nur-Anhang-Protokoll aufbewahren, einen Prüfpfad führen und Ereignisse bei Bedarf wiedergeben.

Schnappschüsse und Optimierung

Bei 9:39 spricht Derek das Thema Snapshotting an. Obwohl sie oft zusammen mit Event Sourcing diskutiert werden, stellt er klar, dass Snapshots eher eine Leistungsoptimierung als eine Kernanforderung sind.

Snapshots reduzieren den Aufwand für die Wiedergabe aller Ereignisse, indem sie regelmäßig einen Teil des Zustands speichern, aber die vollständige Historie ist weiterhin über das Append-Only-Protokoll verfügbar.

Schlüsselunterscheidung: Event Sourcing vs. Ereignisgesteuerte Architektur

Um 10:00 Uhr warnt Derek vor einem weit verbreiteten Missverständnis: Event Sourcing und ereignisgesteuerte Architektur sind unterschiedlich! Tools wie Kafka helfen bei der Datenverteilung, aber echtes Event Sourcing konzentriert sich auf die Aufzeichnung von Domänenereignissen als unveränderlichen Prüfpfad.

Das Verständnis der Unterscheidung ist entscheidend, wenn Sie Event Sourcing in Ihre komplexen Systeme integrieren.

Abschluss

Nach dem Video von Derek Comartin ist klar, dass es beim Event Sourcing darum geht, jede Änderung als Ereignis aufzuzeichnen, nicht nur den Endzustand. Durch die Speicherung von Ereignissen in einem Nur-Anhang-Speichersystem erstellen Sie ein umfangreiches Ereignisschema, das einen Prüfpfad, Flexibilität bei der Abfrage von Ereignissen und robuste Unterstützung für die Trennung der Verantwortlichkeiten bei Befehlsabfragen bietet.

Unabhängig davon, ob Sie sich mit C# Event Sourcing in .NET Core oder einer anderen Plattform befassen, ist Dereks strukturierte Erklärung von Kernkonzepten, Event-Handlern, privaten Sets, geschützten Sets und der Anwendung von Events wie private void Apply() in Ihren Modellen unglaublich wertvoll.

Wenn Sie am Aufbau eines belastbaren Domänenmodells, an der Verbesserung Ihres Speichersystems oder an der Erstellung komplexer Muster mit mehreren Vorteilen wie der letztendlichen Konsistenz arbeiten, ist das Studium von Dereks Ansatz ein Muss. Schauen Sie sich seinen YouTube-Kanal für weitere aufschlussreiche Videos an.