Nicht nur was gilt – sondern wie es dazu kam.
Klassische CRUD-Systeme funktionieren hervorragend, solange hauptsächlich der aktuelle Zustand relevant ist. Bei komplexeren Produkten wird jedoch oft entscheidend, wie ein Zustand entstanden ist.
/ Pragmatisch statt dogmatisch
Nicht jede Tabelle und nicht jede Domäne braucht Event Sourcing. Wir setzen es gezielt dort ein, wo Nachvollziehbarkeit und Entkopplung einen echten Nutzen bringen – andere Bereiche bleiben bewusst bei klassischen relationalen Modellen.
Wann Event Sourcing sinnvoll ist
Event Sourcing macht fachliche Veränderungen explizit und nachvollziehbar: Statt nur den aktuellen Zustand zu speichern, werden relevante Ereignisse wie OrderPlaced, PaymentReceived oder ShipmentConfirmed zur Grundlage des Systems – eine robuste Basis für komplexe Geschäftsprozesse, Integrationen und langfristig weiterentwickelbare Produkte.
- Komplexe Geschäftsprozesse mit mehreren Zuständen und Beteiligten
- Zuverlässige Integration von ERP, Payment, Logistik oder anderen Umsystemen
- Hohe Anforderungen an Nachvollziehbarkeit und Auditierbarkeit
- Asynchrone Abläufe mit Retry- und Fehlerbehandlung
- Systeme, deren fachliche Änderungen langfristig nachvollziehbar bleiben müssen
- Produkte, die über viele Jahre weiterentwickelt werden sollen
Was wir machen
Wir verbinden Domain Driven Design, Event Storming, Event Sourcing, CQRS und Event-Driven Architecture mit praktischer Erfahrung aus produktiven Software- und Integrationssystemen.
- Event Storming und Domain Modelling (Domain Driven Design)
- Definition von Aggregates, Commands, Events und Queries
- Event-Sourcing- und CQRS-Architektur
- Event Stores und Projektionen
- Event-driven Integrationen
- Asynchrone Verarbeitung, Retries und Idempotenz
- Migration bestehender Systeme
- Architektur-Reviews bestehender Event-Sourcing-Lösungen
- Referenzimplementierungen und technische Standards für Entwicklungsteams
Von der Domäne bis zum produktiven System
Wir begleiten Teams, die Event Sourcing neu einführen möchten – und bestehende Systeme, deren Architektur, Event-Modell oder technische Umsetzung überprüft und weiterentwickelt werden sollen.
- Einführung in neuen Produkten und Domänen
- Review und Weiterentwicklung bestehender Lösungen
- Kombination mit klassischen relationalen Modellen, wo diese genügen
Entscheidend ist nicht die Technologie, sondern eine Architektur, die zur fachlichen Komplexität passt.