Tech-USP: Jede Änderung an einer Entität ist ein Event auf einem Aggregat-Stream. Das Änderungsprotokoll ist nicht etwas, das Ihr baut — es ist das Framework.
Käufer-Sicht: Wer hat den Datensatz am 12.3. um 14:32 geändert? — eine Abfrage. ISO-27001-Audit, DSGVO-Auskunft, interne Revision auf Knopfdruck statt im Sprint.
Was das konkret bedeutet
In Kumiko schreibt ein Write-Handler nicht direkt in eine Tabelle, sondern emittiert ein Event:
r.writeHandler({
name: "incident.open",
schema: openIncidentSchema,
handler: async (event, ctx) => {
await ctx.appendEvent("incident-opened", {
incidentId,
title: event.title,
severity: event.severity,
});
},
});Das Event landet in der events-Tabelle (Postgres, kein Kafka). Die Read-Model-Tabelle (incidents) wird via Projection daraus aufgebaut — synchron, in derselben Transaction. Read-after-write „funktioniert einfach”.
Was Du dadurch gratis bekommst
„Wer hat was wann geändert” als Framework-Primitive
yarn kumiko inspect incident <id>Liefert die komplette Event-History für die Entity. Ohne separate Audit-Tabelle, ohne Postgres-Trigger, ohne Drift-Risiko.
„Wie sah’s am 12.3. um 14:32 aus”
const oldState = await ctx.loadAggregate("incident", id, {
asOf: Temporal.Instant.from("2026-03-12T14:32:00Z"),
});Time-Travel als Framework-Primitive. Compliance-Auditor liebt das.
Read-Models sind rebuildbar
Schema-Migration einer Read-Model-Tabelle = Projection neu rebuilden, alte Events upcasten. Schema-Bug, der Daten gefressen hat? Projection drop + rebuild aus dem Event-Log. Original-Daten sind nie weg.
DSGVO-Erasure ohne Audit-Lücke
Crypto-Shredding: Verschlüsselte Felder mit User-spezifischen Keys. „Right to be forgotten” = Key löschen. Aggregate bleibt für Compliance lesbar (Event-Struktur), PII ist mathematisch unleserlich.
Was es nicht ist
- Keine eigene Event-Bus-Infrastruktur — Postgres ist Event-Store. Kein Kafka, kein NATS, kein EventStoreDB
- Keine Pflicht zu DDD-Vokabular — Du kannst Kumiko ohne ein einziges „Aggregate”/„Bounded Context” lernen. Die Events sind unter der Haube, der Author-Layer ist
r.writeHandler({...}) - Kein Performance-Killer — Single-Stream-Projections laufen inline (read-after-write OK). Cross-Aggregate-Projections sind explizit async
- Kein Uber-Scale-Tool — Postgres + Kumiko skaliert für 99% der Business-Apps. >100k events/s gehören zu Kafka
Architektur-Tiefendoku
| Doc | Inhalt |
|---|---|
event-sourcing-pivot | Pivot-Begründung, events-Tabelle, asOf, Aggregate-Streams |
event-dispatcher | Async-Delivery, MultiStreamProjection, Dead-Letter, Retention |
projections | Projection-Patterns (Single-Stream, Cross-Aggregate) |
es-gdpr-strategy | DSGVO + Crypto-Shredding |
es-competitor-scan | Vergleich Marten/Axon/EventStoreDB |
sprint-f-temporal | Temporal-first-class für Time-Travel |
Wo das im Pitch landet
- DACH-Sales: Top-Argument #2 — ISO 27001, DSGVO, interne Revision. Sehr konkret machen mit
kumiko inspect-Demo - Indie-Hacker: Sub-Argument — Enterprise-Deal-Closer („customer asked for change history dashboard”)