Event Sourcing ( Event Sourcing, Ereignisprotokollierung, Ereignisgenerierung) ist ein leistungsstarkes Architekturmuster, in dem alle am Anwendungsstatus vorgenommenen Änderungen in der Reihenfolge gespeichert werden, in der sie aufgetreten sind. Diese Aufzeichnungen dienen sowohl als Quelle für die Ermittlung des aktuellen Status als auch als Prüfpfad für die Ereignisse in der Anwendung während ihrer Lebensdauer. Event Sourcing erleichtert das dezentrale Ändern und Lesen von Daten. Diese Architektur lässt sich gut skalieren und eignet sich für Systeme, die bereits mit der Ereignisbehandlung arbeiten oder auf eine solche Architektur migrieren möchten.
Was ist Event Sourcing?
Domänenexperten beschreiben ihre Systeme normalerweise als eine Sammlung von Entitäten , bei denen es sich um Container zum Speichern von Status und Ereignissen (Ereignissen) handelt , die Änderungen in Entitäten infolge der Verarbeitung von Eingabedaten in verschiedenen Geschäftsprozessen widerspiegeln. Ereignisse werden häufig durch Befehle von Benutzern, Hintergrundprozesse oder Integrationen in externe Systeme ausgelöst .
Im Wesentlichen konzentriert sich Event Sourcing auf Ereignisse im Zusammenhang mit Änderungen im System.
Viele Architekturmuster betrachten Entitäten als primäres Konzept. Diese Vorlagen beschreiben, wie Sie sie speichern, auf sie zugreifen und sie ändern. Innerhalb dieses architektonischen Stils sind Ereignisse oft "seitwärts": Sie sind die Konsequenzen wechselnder Einheiten.
In der Regel basieren diese Architekturen auf einem Entitätsspeicher wie einer relationalen Datenbank oder einem Dokumentenspeicher. Obwohl Ereignisse in einer solchen Architektur vorhanden sein können, sind sie im Wesentlichen kein primäres Konzept und können von den Entitäten, denen sie zugeordnet sind, getrennt und hinter Schichten der Geschäftslogik verborgen werden.
Event Sourcing kehrt diesen Ansatz um, indem es sich auf die Implementierung von Ereignissen konzentriert: wie sie fortbestehen und wie sie verwendet werden können, um den Status einer Entität zu erhalten. In diesem Fall enthält die Datenbank ein sequentielles Protokoll aller Ereignisse, die während der Lebensdauer des Systems aufgetreten sind.
Im Folgenden finden Sie einen Vergleich des Ereignisspeichers mit dem Entity Store (später ausführlicher beschrieben): Die
Ereignisbeschaffung, bei der Ereignisse als Hauptarchitekturkonzept verwendet werden, ist auch ein Paradigma für die Domänenmodellierung, das die Sicht des Kunden auf das System besser widerspiegelt. Das Entwerfen von Systemen mit Schwerpunkt auf Ereignissen und Ereignisprotokollen bietet die folgenden Vorteile:
- , « » .
- (command/query responsibility), .
- , , , .
Event Sourcing
Schauen wir uns ein einfaches Beispiel mit einem Bankkonto an. Wir werden ein Unternehmen haben , das ein Bankkonto vertritt. Der Einfachheit halber erstellen wir nur ein Konto, ohne es anhand der Kontonummer oder auf andere Weise zu identifizieren. Das Konto behält den aktuellen Kontostand bei.
Für das Konto stehen zwei Befehle (Befehl) zur Verfügung : Einzahlung (Einzahlung) und Auszahlung (Auszahlung). Die Befehle geben den Betrag an, der eingezahlt oder abgehoben werden soll. Wir werden auch eine Geschäftsregel definieren, die überprüft, dass ein Auszahlungsbefehl nur verarbeitet werden kann, wenn der angeforderte Betrag dem aktuellen Kontostand entspricht oder darunter liegt.
Mit diesem Ansatz können zwei Ereignisse unterschieden werden (Ereignis)- "Konto gutgeschrieben" und "Konto belastet". Diese Ereignisse enthalten Informationen über den Betrag, der eingezahlt oder abgehoben wurde. Dies könnte zu einem Ereignis mit einer positiven oder negativen Summe vereinfacht werden, aber in diesem Beispiel werden wir sie aufteilen.
Das folgende Diagramm zeigt das Datenmodell.
Beachten Sie, dass Ereignisse Vergangenheitsform sind. Sie geben an, was zum Zeitpunkt des Schreibens im System passiert ist, und werden nur gespeichert, wenn der Befehl erfolgreich verarbeitet wurde. Bei diesem Ansatz muss darauf geachtet werden, Befehle nicht mit Ereignissen zu verwechseln. Besonders wenn sie sich spiegeln.
Die Reihenfolge der Befehle kann folgendermaßen aussehen:
1. Einzahlung {Betrag: 100} - Einzahlung 100
2. {Betrag: 80} abheben - 80 abheben
3. {Betrag: 50} abheben - 50 abheben
Die einfachste Implementierung von Event Sourcing erfordert ein Ereignisprotokoll , das einfach eine Folge von Ereignissen ist. Bei der Verarbeitung der obigen Befehle erhalten Sie ein solches Protokoll.
Der dritte Befehl kann nicht ausgeführt werden, da der angeforderte Betrag den verfügbaren Kontostand überschreitet.
Um den aktuellen Kontostand zu erhalten, muss das System Ereignisse in der Reihenfolge ihres Auftretens verarbeiten oder "generieren". In unserem Beispiel könnte es so aussehen:
- Bankkonto {aktueller Kontostand: 0} (Startstatus)
Bankkonto {aktueller Kontostand: 0} (Startstatus) - bank account { current balance: 100 } (processed: Account Credited, +100)
{ : 100 } (: , +100) - bank account { current balance: 20 } (processed: Account Debited, -80)
{ : 20 } (: , -80)
Der aktuelle Saldo wird durch die Verarbeitung aller Ereignisse bis zum aktuellen Zeitpunkt berechnet. Da jedes Ereignis einen impliziten Zeitstempel hat, kann der Status des Kontos jederzeit berechnet werden, indem alle Ereignisse für den erforderlichen Zeitraum verarbeitet werden.
Dies ist ein vollständiges (wenn auch triviales) Beispiel für Event Sourcing. In einem realen System muss dieses Beispiel höchstwahrscheinlich erweitert werden.
Es kann erforderlich sein, eine Folge von Befehlen zu speichern, um zu identifizieren, wie das Ereignis aufgetreten ist, und ein separates Fehlerereignisprotokoll zu erstellen, in dem fehlgeschlagene Befehle aufgezeichnet werden können, um weitere Fehler zu behandeln und eine vollständige Historie erfolgreicher und erfolgreicher Ereignisse aufrechtzuerhalten erfolglose Teams.
Mit zunehmender Zeit, wenn die Anzahl der Befehle zunimmt, kann es erforderlich sein, einen aktuellen Kontostand aufrechtzuerhalten, so dass es beim Empfang eines Auszahlungsbefehls nicht erforderlich ist, die vollständige Liste der Ereignisse zu verarbeiten, um festzustellen, ob der Befehl ausgeführt werden kann (d. H. Wenn das Konto über genügend Guthaben verfügt). Dies ist ein Beispiel für einen abgeleiteten Speicher und entspricht im Wesentlichen einem Entitätsspeicher.
Nachfolgend sehen Sie, wie der Entitätsspeicher nach der Verarbeitung aller Befehle nach unserem Beispiel sucht.
Im Vergleich zu einem vollwertigen Event Store ist dies offensichtlich ein sehr primitives Beispiel. Dies ist einer der Gründe, warum viele Entwickler nur den Entity Store verwenden. In diesem Fall ist der Leistungsbilanzsaldo sofort verfügbar und es müssen nicht alle historischen Ereignisse verarbeitet werden.
Event Sourcing schließt jedoch Entity Stores nicht aus. Häufig sind Entity Stores auch in Event Sourcing-Projekten vorhanden.
Ende des ersten Teils.
