Lesen Sie den ersten Teil.
Merkmale der Implementierung von Event Sourcing
Aus technischer Sicht erfordert Event Sourcing nur die Implementierung von Protokollierungsereignissen und das Lesen aus dem Protokoll.
Im einfachsten Fall kann eine Datei als Ereignisspeicher verwendet werden, in dem ein separates Ereignis in jeder Zeile oder mehrere Dateien aufgezeichnet werden, wenn jedes Ereignis in einer separaten Datei gespeichert wird. In der Regel werden in großen Systemen, die Parallelität und Skalierbarkeit erfordern, zuverlässigere Speichermethoden verwendet.
Das Ereignisprotokoll ist ein sehr verbreitetes Muster, das in Verbindung mit Message Broker (Message-Oriented Middleware) und Ereignisstrom-Verarbeitungssystemen verwendet wird. Ein Nachrichtenbroker, der als Ereignisprotokoll verwendet wird, kann bei Bedarf den gesamten Nachrichtenverlauf speichern.
Relationale und dokumentarische Modelle konzentrieren sich normalerweise auf die Entitätsmodellierung. In solchen Modellen ist der aktuelle Status leicht durch Lesen einer oder mehrerer Zeilen oder Dokumente zu erhalten. Es ist erwähnenswert, dass sich Event Sourcing und das relationale Modell nicht gegenseitig ausschließen. Event-Sourcing-Systeme umfassen häufig beides. Der Hauptunterschied zu Event Sourcing besteht darin, dass der Entitätsspeicher nicht mehr als Rohdaten behandelt wird. Es kann durch Wiederaufbereitung des Ereignisprotokolls ersetzt oder neu erstellt werden.
In komplexeren Event-Sourcing-Systemen müssen abgeleitete Statusspeicher für effiziente Leseanforderungen vorhanden sein, da das Abrufen des aktuellen Status durch Verarbeiten des gesamten Ereignisprotokolls im Laufe der Zeit die Skalierung stoppen kann. Sowohl relationale als auch Dokumentdatenbanken können sowohl als Ereignisprotokoll als auch als Repository für abgeleitete Entitäten verwendet werden, über die Sie schnell den aktuellen Status abrufen können. Tatsächlich handelt es sich bei dieser Trennung von Bedenken um CQRS (Command Query Responsibility Segregation). Alle Anforderungen werden an den abgeleiteten Speicher weitergeleitet, damit dieser unabhängig von Schreibvorgängen optimiert werden kann.
Neben dem technischen Teil gibt es noch weitere Punkte, die es wert sind, beachtet zu werden.
Mögliche Probleme bei der Beschaffung von Ereignissen
Trotz der Vorteile von Event Sourcing hat es auch Nachteile.
Die größten Herausforderungen liegen normalerweise in der Denkweise der Entwickler. Entwickler müssen über herkömmliche CRUD-Anwendungen und Entity-Stores hinausgehen. Ereignisse sollten nun zum Hauptkonzept werden.
Mit Event Sourcing wird viel Aufwand für die Modellierung von Ereignissen aufgewendet. Nachdem die Ereignisse in das Protokoll geschrieben wurden, müssen sie andernfalls als unverändert betrachtet werden, und Verlauf und Status können beschädigt oder beschädigt sein. Das Ereignisprotokoll besteht aus den Rohdaten. Dies bedeutet, dass Sie sehr vorsichtig sein müssen, um sicherzustellen, dass es alle Informationen enthält, die erforderlich sind, um den vollständigen Status des Systems zu einem bestimmten Zeitpunkt zu erhalten. Es sollte auch berücksichtigt werden, dass Ereignisse neu interpretiert werden können, wenn sich das System (und das Geschäft, das es darstellt) im Laufe der Zeit ändert. Und vergessen Sie nicht fehlerhafte und verdächtige Ereignisse bei korrekter Verarbeitung der Datenvalidierung.
Bei einfachen Domänenmodellen kann diese Änderung des Denkens recht einfach sein, bei komplexeren Domänenmodellen kann sie jedoch ein Problem darstellen (insbesondere bei vielen Abhängigkeiten und Beziehungen zwischen Entitäten). Die Integration in externe Systeme, die zu einem bestimmten Zeitpunkt keine Daten bereitstellen, kann schwierig sein.
Event Sourcing kann auf großen Systemen gut funktionieren, da das Ereignisprotokollmuster natürlich horizontal skaliert. Beispielsweise muss sich das Ereignisprotokoll einer Entität nicht physisch im Ereignisprotokoll einer anderen Entität befinden. Diese einfache Skalierung führt jedoch zu zusätzlichen Problemen in Form einer asynchronen Verarbeitung und schließlich zu konsistenten Daten. Befehle zum Ändern des Status können an jeden Knoten gesendet werden. Anschließend muss das System ermitteln, welche Knoten für die entsprechenden Entitäten verantwortlich sind, und den Befehl an diese Knoten senden, dann den Befehl verarbeiten und die generierten Ereignisse auf andere Knoten replizieren, auf denen die Ereignisprotokolle gespeichert sind. Und erst nach Abschluss dieses Vorgangs wird das neue Ereignis als Teil des Systemstatus verfügbar.Daher erfordert Event Sourcing tatsächlich, dass die Befehlsverarbeitung von der Statusanforderung, d. H. CQRS, getrennt ist.
Daher müssen Event-Sourcing-Systeme das Zeitintervall zwischen der Ausgabe eines Befehls und dem Empfang einer Benachrichtigung über eine erfolgreiche Ereignisprotokollierung berücksichtigen. Der Systemstatus, den Benutzer zu diesem Zeitpunkt sehen, ist möglicherweise "falsch". Oder besser gesagt, ein bisschen veraltet. Um den Einfluss dieses Faktors zu verringern, muss er beim Entwurf der Benutzeroberfläche und in anderen Komponenten berücksichtigt werden. Es ist auch erforderlich, Situationen ordnungsgemäß zu behandeln, in denen ein Befehl fehlschlägt, während der Ausführung abgebrochen wird oder ein Ereignis durch ein neueres ersetzt wird, wenn Daten aktualisiert werden.
Ein weiteres Problem tritt auf, wenn sich Ereignisse im Laufe der Zeit ansammeln und mit ihnen gearbeitet werden muss. Es ist eine Sache, sie nach der Verarbeitung einfach aufzuschreiben, eine andere, mit der gesamten Geschichte zu arbeiten. Ohne diese Funktionalität verliert das Ereignisprotokoll seinen Wert vollständig. Dies gilt insbesondere für die Notfallwiederherstellung oder bei der Migration abgeleiteter Speicher, bei denen möglicherweise alle Ereignisse erneut verarbeitet werden müssen, um die Daten zu aktualisieren. Bei Systemen mit einer großen Anzahl von Ereignissen kann die Wiederaufbereitung des gesamten Protokolls die zulässige Wiederherstellungszeit überschreiten. Hier können regelmäßige System-Snapshots hilfreich sein, damit Sie sich von einem späteren fehlerfreien Zustand erholen können.
Es ist auch notwendig, die Struktur der Ereignisse zu berücksichtigen. Die Struktur von Ereignissen kann sich im Laufe der Zeit ändern. Der Satz von Feldern kann sich ändern. Es kann Situationen geben, in denen alte Ereignisse von der aktuellen Geschäftslogik verarbeitet werden müssen. Und das Vorhandensein eines erweiterbaren Ereignisschemas wird in Zukunft dazu beitragen, bei Bedarf neue Ereignisse von alten zu unterscheiden. Regelmäßige Schnappschüsse helfen auch dabei, wichtige Änderungen in der Struktur von Ereignissen zu isolieren.
Schlussfolgerungen
Event Sourcing ist ein leistungsstarker Ansatz mit Vorteilen. Eine davon besteht darin, die zukünftige Erweiterung des Systems zu vereinfachen. Da im Ereignisprotokoll alle Ereignisse gespeichert sind, können sie in externen Systemen verwendet werden. Die Integration durch Hinzufügen neuer Ereignishandler ist recht einfach.
Wie bei jeder wichtigen architektonischen Entscheidung müssen Sie jedoch darauf achten, dass sie für Ihre Situation geeignet ist. Einschränkungen in Bezug auf die Komplexität der Domäne, die Anforderungen an die Datenkonsistenz und -verfügbarkeit sowie die langfristige Erhöhung des Volumens gespeicherter Daten und die Skalierbarkeit müssen berücksichtigt werden (und dies ist keineswegs eine vollständige Liste). Ebenso wichtig ist es, auf die Entwickler zu achten, die ein solches System während seines gesamten Lebenszyklus entwickeln und warten.
Und schließlich vergessen Sie nicht das wichtigste Prinzip der Softwareentwicklung - bemühen Sie sich, alles so einfach wie möglich zu halten (das KISS-Prinzip).
