Event Sourcing und CQRS — Eine Alternative zu CRUD

Event Sourcing¶

Statt UPDATE account SET balance = 950 speichern Sie ein Event: AccountDebited(amount=50). Aktueller Zustand = Replay aller Events. Audit Trail inklusive, Time-Travel-Debugging und die Möglichkeit, in verschiedene Views zu projizieren.

// Order events
OrderCreated { orderId: "123", customerId: "456" }
LineAdded { orderId: "123", productId: "789", qty: 2 }
LineAdded { orderId: "123", productId: "012", qty: 1 }
OrderSubmitted { orderId: "123", timestamp: "2016-11-10T10:30:00Z" }
PaymentReceived { orderId: "123", amount: 1500.00 }
OrderShipped { orderId: "123", trackingNumber: "CZ123456" }

// Current state = replay of these events

CQRS: Command Query Responsibility Segregation¶

Trennung des Write-Modells (Commands) vom Read-Modell (Queries). Das Write-Modell ist optimiert für Geschäftslogik und Validierung. Das Read-Modell ist optimiert für Abfragen — denormalisiert, materialisierte Views, Suchindizes.

Wann es Sinn ergibt¶

• Komplexe Domänenlogik (DDD)
• Audit-Anforderungen (Finanzen, Gesundheitswesen)
• Verschiedene Read-Modelle aus denselben Daten (Dashboard, Report, Suche)
• Event-driven Architektur mit Kafka

Wann nicht¶

• Einfache CRUD-Anwendungen — Overkill
• Kleines Team ohne DDD-Erfahrung
• Systeme, die starke Konsistenz erfordern (Eventual Consistency ist ein Trade-off)

ES/CQRS ist ein mächtiges Pattern für die richtigen Probleme¶

Event Sourcing und CQRS sind kein Allheilmittel. Aber für Systeme mit komplexen Domänen, Audit-Anforderungen und Event-driven Architektur sind sie ein Game Changer.