Katalog
concept#Produkt#Delivery#Ereignisquellen

Event Sourcing

Event Sourcing ist ein Architekturansatz, bei dem Änderungen an einem System als eine Sequenz von Ereignissen gespeichert werden.

Event Sourcing ist ein Architekturansatz, der es ermöglicht, den Zustand eines Systems durch die Speicherung von Ereignissen nachzuvollziehen.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Datenbanken zur Speicherung von EreignissenMessaging-Systeme zur EreignisübertragungMonitoring-Tools zur Überwachung von Ereignissen

Prinzipien & Ziele

Ereignisse sind unveränderlich.Der Zustand wird aus Ereignissen rekonstruiert.Ereignisse sind die Quelle der Wahrheit.
Umsetzung
Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Missmanagement von Ereignissen kann zu Inkonsistenzen führen.
  • Ereignisse können schwer zu debuggen sein.
  • Übermäßige Speicherung kann zu hohen Kosten führen.
  • Ereignisse klar und präzise definieren.
  • Ereignisse in der richtigen Reihenfolge verarbeiten.
  • Regelmäßige Überprüfung der Ereignisarchitektur.

I/O & Ressourcen

  • Ereignisse, die den Zustand ändern
  • Ereignis-Handler zur Verarbeitung
  • Persistente Speicherung für Ereignisse
  • Aktualisierte Zustände basierend auf Ereignissen
  • Historie der Ereignisse
  • Audit-Logs für Compliance

Beschreibung

Event Sourcing ist ein Architekturansatz, der es ermöglicht, den Zustand eines Systems durch die Speicherung von Ereignissen nachzuvollziehen. Anstatt den aktuellen Zustand direkt zu speichern, werden alle Änderungen als Ereignisse aufgezeichnet. Dies ermöglicht eine vollständige Historie der Änderungen und erleichtert die Wiederherstellung von Zuständen zu einem bestimmten Zeitpunkt.

  • Vollständige Nachvollziehbarkeit von Änderungen.
  • Erleichterte Wiederherstellung von Zuständen.
  • Bessere Unterstützung für Audits und Compliance.

  • Komplexität bei der Verwaltung von Ereignissen.
  • Potenzielle Performance-Probleme bei großen Datenmengen.
  • Erfordert ein Umdenken in der Datenarchitektur.

  • Anzahl der gespeicherten Ereignisse

    Die Gesamtzahl der Ereignisse, die im System gespeichert sind.

  • Durchschnittliche Wiederherstellungszeit

    Die durchschnittliche Zeit, die benötigt wird, um einen Zustand aus Ereignissen wiederherzustellen.

  • Ereignisverarbeitungszeit

    Die Zeit, die benötigt wird, um ein Ereignis zu verarbeiten.

Bankanwendung

Eine Bankanwendung, die alle Transaktionen als Ereignisse speichert, um eine vollständige Historie der Kontobewegungen zu gewährleisten.

E-Commerce-Plattform

Eine E-Commerce-Plattform, die Bestellungen und Zahlungen als Ereignisse speichert, um den Bestellstatus nachverfolgen zu können.

Content-Management-System

Ein CMS, das Änderungen an Inhalten als Ereignisse speichert, um die Historie von Änderungen nachvollziehbar zu machen.

1

Definieren Sie die Ereignisse, die gespeichert werden sollen.

2

Implementieren Sie die Ereignis-Handler.

3

Richten Sie die persistente Speicherung ein.

⚠️ Technische Schulden & Engpässe

  • Unzureichende Infrastruktur für Ereignisse.
  • Mangelnde Dokumentation von Ereignissen.
  • Fehlende Tests für Ereignis-Handler.
EreignisverwaltungDatenkonsistenzSkalierbarkeit
  • Ereignisse als temporäre Daten verwenden.
  • Ereignisse nicht korrekt speichern.
  • Ereignisse nicht für Audits nutzen.
  • Annahme, dass Ereignisse einfach zu verwalten sind.
  • Glaube, dass alle Ereignisse gleich wichtig sind.
  • Unterschätzung der Komplexität der Ereignisverarbeitung.
Kenntnisse in der Ereignisgesteuerten ArchitekturErfahrung mit DatenpersistenzFähigkeit zur Analyse von Ereignisdaten
Ereignisgesteuerte ArchitekturMicroservices-ArchitekturDatenpersistenzstrategien
  • Ereignisse müssen unveränderlich sein.
  • Ereignisse müssen in der richtigen Reihenfolge verarbeitet werden.
  • Technische Infrastruktur muss vorhanden sein.