Event Sourcing in der Praxis: Nicht nur Datenversionierung, sondern ein leistungsstarkes Analysewerkzeug

Heute möchte ich ein architektonisches Muster diskutieren, das in komplexen Geschäftsanwendungen verbreitet, aber oft unterschätzt wird: die „Event-Sourced Entity" oder, einfach ausgedrückt, ein robustes Datenversionierungssystem.

Was ist das?

Im klassischen CRUD-Modell aktualisieren wir einen Datensatz direkt in einer Tabelle wie products: price = 1000. Die Änderungshistorie geht dabei stillschweigend verloren.

Das ereignisgesteuerte Modell funktioniert anders:

Die Hauptentität speichert nur den aktuellen Zustand (z. B. den neuesten Preis, den Lagerbestand).
Jede Änderung (ein Ereignis) wird in einer separaten Protokolltabelle als unabhängiger, unveränderlicher Eintrag aufgezeichnet.
Der aktuelle Zustand ist das Ergebnis der sequenziellen Anwendung aller historischen Ereignisse.

Ein einfaches Laravel-Beispiel

Betrachten wir eine ProductPricing-Entität.

1. Migrationen:

// Haupttabelle (aktueller Zustand) Schema::create('product_pricings', function (Blueprint $table) { $table->id(); $table->foreignId('product_id')->constrained(); $table->decimal('price', 10, 2); $table->integer('stock'); $table->timestamps(); }); // Ereignistabelle (Historie) Schema::create('pricing_events', function (Blueprint $table) { $table->id(); $table->foreignId('product_pricing_id')->constrained()->onDelete('cascade'); $table->string('type'); // 'price_changed', 'stock_incremented' $table->json('payload'); // { "old_price": 100, "new_price": 120, "reason": "supplier_cost" } $table->timestamp('performed_at'); $table->foreignId('user_id')->nullable(); // Wer es initiiert hat });

2. Modell und Ereignis:

// Event Data Transfer Object class PriceChangedEvent { public function __construct( public float $oldPrice, public float $newPrice, public string $changedBy, public ?string $reason = null ) {} } // ProductPricing Model class ProductPricing extends Model { public function events() { return $this->hasMany(PricingEvent::class); } public function changePrice(float $newPrice, User $user, string $reason): void { // 1. Das Ereignis aufzeichnen $this->events()->create([ 'type' => 'price_changed', 'payload' => new PriceChangedEvent( oldPrice: $this->price, newPrice: $newPrice, changedBy: $user->email, reason: $reason ), 'performed_at' => now(), 'user_id' => $user->id, ]); // 2. Den aktuellen Zustand aktualisieren $this->update(['price' => $newPrice]); } }

Vorteile dieses Ansatzes:

✅ Vollständiger Audit-Trail & Rückverfolgbarkeit. Wir wissen nicht nur, was sich geändert hat, sondern auch wann, von wem und warum. Unschätzbar für Compliance und die Beilegung von Streitigkeiten.

✅ Rekonstruktion des Zustands zu einem bestimmten Zeitpunkt. Wir können das Modell auf jeden vergangenen Moment „zurückspielen", indem wir die Ereignisse bis zu diesem Punkt neu berechnen.

✅ Entkoppelte Geschäftslogik. Ereignisse sind reine Fakten. Sie können asynchron verarbeitet, an Message Queues (RabbitMQ, Kafka) gesendet werden.

✅ Grundlage für CQRS. Das Ereignisprotokoll ist eine perfekte Single Source of Truth für den Aufbau verschiedener Lesemodelle (z. B. spezialisiert auf Reporting).

Nachteile und Komplexitäten:

❌ Erhöhte Komplexität. Die Architektur wird komplexer als „einfaches CRUD". Die Konsistenz zwischen Haupttabelle und Ereignissen muss verwaltet werden.

❌ Performance-Overhead. Statt eines Updates führen wir mindestens zwei Schreibvorgänge durch. Overkill für Hochdurchsatzsysteme, bei denen die Historie nicht benötigt wird.

❌ Abfragen der Historie. Die Analyse von Daten erfordert die Arbeit mit großen Ereignisströmen, was nicht trivial sein kann.

Wo ist es besonders nützlich? Der wichtigste Anwendungsfall: Analytik.

Dieser Ansatz ist eine Goldgrube für Datenanalysten und Business Intelligence. Warum?

Trendanalyse & Dynamik: Erstellen Sie ganz einfach Diagramme der Produktpreisänderungen über die Zeit, analysieren Sie Saisonalität und korrelieren Sie mit Marketingkampagnen.
Metrikberechnung: Durchschnittspreis über einen Zeitraum, Lagerumschlagsrate, Häufigkeit von Anpassungen.
Ursachenanalyse: Die Gruppierung von Ereignissen nach Grund oder user_id zeigt, was Änderungen am häufigsten antreibt: Währungsschwankungen, Wettbewerberaktionen, saisonale Nachfrage.
„Was-wäre-wenn"-Modellierung: Auf Basis historischer Ereignisse können Sie Simulationen erstellen. „Was passiert mit dem Gewinn, wenn wir den Preis um X % in Zeitraum Y erhöhen?"

Beispiel-SQL-Abfrage für die Analytik:

-- Die Preishistorie eines bestimmten Produkts über den letzten Monat abrufen SELECT DATE(performed_at) as change_date, JSON_UNQUOTE(JSON_EXTRACT(payload, '$.new_price')) as price, JSON_UNQUOTE(JSON_EXTRACT(payload, '$.reason')) as change_reason FROM pricing_events WHERE product_pricing_id = 123 AND type = 'price_changed' AND performed_at >= NOW() - INTERVAL 30 DAY ORDER BY performed_at;

Fazit

Das Muster „Event-Sourced Entity" ist mehr als nur „den alten Wert speichern". Es ist ein Paradigmenwechsel vom Denken in „Zuständen" zum Denken in „Prozessen" und „Historie".

Verwenden Sie es, wenn:

Gesetzliche Audit-Trails erforderlich sind (Pharma, Finanzen, B2G).
Der Geschäftsprozess eine Abfolge bedeutungsvoller Ereignisse ist (Bestellung: erstellt → bezahlt → erfüllt → versandt).
Sie dringend tiefgehende Analytik zu sich ändernden Schlüsselmetriken benötigen (Preise, Lagerbestand, Raten, Bewertungen).

Es ist eine Investition in die Architektur, die sich durch Transparenz, Flexibilität und Datentiefe für die Entscheidungsfindung auszahlt.

Technologien & Themen

Artikel-Tags

Keine Artikel entsprechen diesen Filtern.

Event Sourcing in der Praxis: Nicht nur Datenversionierung, sondern ein leistungsstarkes Analysewerkzeug

Event Sourcing in der Praxis: Nicht nur Datenversionierung, sondern ein leistungsstarkes Analysewerkzeug

Artikel-Tags

Haben Sie ein Projekt oder eine Idee zu besprechen?