Angebote
EventSourcingDB-Paket
Ereignisgetriebene Fachsysteme mit nachvollziehbarer Historie — auf Basis der EventSourcingDB von the native web.
„Wir können im Nachhinein nicht nachvollziehen, wie ein Zustand zustande kam.“
- Format
- Proof of Value in 3 Wochen, danach Ausbau in Iterationen
- Für wen
- Teams mit prüfpflichtiger Fachlogik, Auditanforderungen oder komplexer Historie
Woran Sie es merken
- Auf die Frage „Wie kam dieser Wert zustande?“ hilft nur noch die Datenbank-Archäologie.
- Audits und Nachweise werden manuell aus Logs und Tabellen zusammengesucht.
- Statusfelder wurden über Jahre erweitert und niemand kennt alle gültigen Übergänge.
- Fachbereiche wollen Auswertungen, die im aktuellen Datenmodell nicht beantwortbar sind.
- Ein Zwischenstand wird beim Speichern überschrieben — die Zwischenschritte sind weg.
Ergebnis
- Bewertung, ob Event Sourcing hier trägt — inklusive ehrlicher Gegenrede
- Referenzimplementierung eines fachlichen Schnitts
- Integration in bestehende Systeme und Read-Model-Strategie
- Enablement des internen Teams inkl. Betriebsfragen
Wie wir vorgehen
01
Woche 1 — Eignung prüfen
Wir modellieren einen fachlichen Ausschnitt entlang der Ereignisse und prüfen, ob Event Sourcing hier wirklich trägt. Wenn nicht, sagen wir das nach einer Woche — nicht nach einem Quartal.
02
Woche 2 — Referenzschnitt
Ein fachlicher Schnitt wird lauffähig umgesetzt: Ereignisse, Projektionen, Read Models und die Anbindung an das bestehende System.
03
Woche 3 — Betrieb & Bewertung
Backup, Migration von Ereignissen, Betriebsfragen und Lasttest im realistischen Rahmen. Am Ende steht eine belastbare Empfehlung mit Aufwandskorridor.
04
Danach — Ausbau in Iterationen
Weitere Schnitte im gleichen Muster, zunehmend durch euer Team. Wir begleiten, statt dauerhaft zu liefern.
Häufige Fragen
- Warum Event Sourcing?
- Weil die Frage irgendwann kommt: Wer hat wann was geändert, und können Sie das unveränderlich belegen? Ein System, das nur den aktuellen Stand speichert, kann darauf nicht antworten. Wir setzen es dort ein, wo Nachweis, Rekonstruktion oder Rechtssicherheit zählen — und sagen ausdrücklich, wo es die falsche Antwort ist.
- Brauchen wir dafür wirklich Event Sourcing?
- Oft nicht. Wenn keine nachvollziehbare Historie, keine Auditpflicht und keine komplexen Zustandsübergänge im Spiel sind, reicht ein klassisches Datenmodell. Genau das prüfen wir zuerst.
- Warum die EventSourcingDB und nicht eine eigene Lösung?
- Weil selbstgebaute Event Stores erfahrungsgemäß an Details scheitern: Reihenfolge, Idempotenz, Migration, Betrieb. Die EventSourcingDB von the native web löst das als Produkt — wir sind auf Umsetzung und Fachlichkeit fokussiert.
- Müssen wir das gesamte System umstellen?
- Nein. Wir setzen dort an, wo Historie wirklich wertvoll ist, und lassen den Rest so, wie er ist. Ereignisgetrieben und CRUD dürfen nebeneinander bestehen.
- Wie ist es um Datenschutz und Löschpflichten bestellt?
- Personenbezogene Daten werden nicht in die Ereignisse geschrieben, sondern referenziert oder kryptografisch löschbar gehalten. Das klären wir im Proof of Value, nicht später.
- Was liegt nach drei Wochen vor?
- Ein lauffähiger Referenzschnitt, eine Read-Model- und Integrationsstrategie, Betriebs- und Lizenzklarheit sowie eine schriftliche Empfehlung inklusive Aufwandskorridor.
Wann das nicht passt
Wenn Ihr Kernproblem Lieferfähigkeit oder Betrieb ist, löst Event Sourcing nichts. Dann sind Production-Readiness oder eine schrittweise Modernisierung der bessere Einstieg.
Passt oft dazu
Hintergrund dazu im Beitrag Event Sourcing ohne Angst: wann es sich lohnt und wann nicht.