Event Sourcing und As-of-Abfragen

In Ordo wird finanzieller Zustand nie aktualisiert; Ereignisse werden angefügt. Der heutige Saldo eines Vertrags wird deterministisch abgeleitet, indem die seit Abschluss angesammelten Ereignisse gefaltet werden (Zahlungen, Gebühren, Zuteilung, Bereitstellung, Restrukturierung …).

Warum?

• Prüffähigkeit: Die Antwort auf „Woher kommt diese Zahl?“ ist die Ereigniskette, die sie erzeugt hat. Weil die Kette append-only ist, ist die Antwort immer eindeutig.
• Replay: Eine Korrektur fügt ein Korrekturereignis an, statt Geschichte zu löschen. Was wann korrigiert wurde, ist selbst ein dauerhafter Eintrag.
• Eine einzige Berechnungsquelle: Ein Saldo ist nie „eine gespeicherte Zahl“; jeder Kanal leitet dasselbe Ergebnis aus denselben Ereignissen ab.

As-of-Abfragen

Die meisten Lese-Endpunkte unterstützen einen asOf-Parameter und reproduzieren den Zustand mit dem Wissensstand des Systems an jenem Tag:

GET /api/v1/contracts/ctr_01J8ZK4T2M/statement?asOf=2026-03-31

Die Antwort für asOf=2026-03-31 wird mit dem Ereignisbestand zum Abschluss des 31. März berechnet — und mit den an jenem Tag gültigen, fixierten Regelwerksversionen, nicht den heutigen. Prüfungen und die rückwirkende Verifikation von BDDK-Meldungen stützen sich auf diesen Mechanismus.

Aufbau eines Ereigniseintrags

{
  "eventId": "evt_01J9AB3XKQ",
  "type": "PAYMENT_SETTLED",
  "occurredAt": "2026-08-20T09:14:33Z",
  "contractId": "ctr_01J8ZK4T2M",
  "payload": {
    "amountMinor": 250000,
    "currency": "TRY",
    "installmentNo": 14
  },
  "actor": { "userId": "ops-user-1", "channel": "OPS_CONSOLE" },
  "traceId": "8f4a2c1e-9b3d-4e7f-a1c2-5d6e7f8a9b0c"
}

Jedes Ereignis trägt seinen Akteur, den Kanal und die traceId. Administrative Aktionen (Freigaben, Berechtigungsänderungen) leben im selben Journal — die finanzielle Spur und die operative Spur werden nie getrennt.

Laufzeitumgebung und Persistenz

Der Identity Provider und die Kern-API laufen auf Cloudflare Containers; die Persistenz liegt auf Managed Postgres:

• die Realm-Daten des Identity Providers,
• der Event Store (die Tabelle es.events),
• der Prüfpfad.

Das ereignisbasierte Journalmodell bleibt auf dieser Infrastruktur unverändert: Das Journal bleibt append-only, und der Zustand wird weiterhin durch das Falten der Ereignisse abgeleitet.