56 lines
3.8 KiB
Markdown
56 lines
3.8 KiB
Markdown
|
# ADR-0001: Erster produktiver Rollout — eigene DB-App als Senke UND Datenquelle
|
||
|
|
|
||
|
|
- **Status:** accepted
|
||
|
|
- **Datum:** 2026-10-25
|
||
|
|
- **Entscheider:** CEO (A. Leinen), CTO
|
||
|
|
- **Betroffene Dokumente:** `docs/architecture/v1.1.md` Abschnitte 7.2, 10 (Phase 4), 12
|
||
|
|
|
||
|
|
## Kontext und Problemstellung
|
||
|
|
|
||
|
|
ProofedMesh soll in einem ersten produktiven Durchlauf einen vollständig attestierten Reisekostenprozess abbilden: Benutzer wählt im Chat ein Projekt, Agenten holen Vorab-Infos und bauen eine Buchungsnutzlast, eine Senke übernimmt. Der Trust-Core (Approval, Signing, Verification, OPA, Trillian) muss sich dabei einmal end-to-end gegen echte Komponenten beweisen.
|
||
|
|
|
||
|
|
Zwei Fragen sind zu entscheiden: (1) *Welche Senke* ist die erste produktive? (2) *Wo* holen Agenten ihre Vorab-Lesedaten?
|
||
|
|
|
||
|
|
## Entscheidungsoptionen
|
||
|
|
|
||
|
|
- **Option A — SAP S/4HANA zuerst** (Senke + evtl. OData als Datenquelle).
|
||
|
|
- **Option B — eigene kleine Go-DB-App** als Senke `sink:expense-db-app` und Datenquelle `ds:expense-db-app` im selben Prozess.
|
||
|
|
- **Option C — HTTP-Webhook an einen externen Dritt-Dienst** als Senke, kein eigener Datenquellen-Dienst.
|
||
|
|
|
||
|
|
## Entscheidung
|
||
|
|
|
||
|
|
**Option B.** Wir bauen eine kleine Go-DB-App (`expense-db-adapter` + `expense-db-postgres`), die zugleich Senke und Datenquelle ist, und nutzen sie für den ersten produktiven Rollout.
|
||
|
|
|
||
|
|
### Begründung
|
||
|
|
|
||
|
|
- **Kleinster Blast Radius.** Fehler im Trust-Core gefährden hier nur unsere eigene Instanz, keinen produktiven SAP-Mandanten.
|
||
|
|
- **Schema-Hoheit bei uns.** Wir können `expense.canonical`, `ds.expense.project_assignment` und `sink.db.expense` so modellieren, wie es für den sauberen Durchlauf gebraucht wird; keine Rücksicht auf vorhandene ERP-Felder in Runde 1.
|
||
|
|
- **Deckt beide Pfade in einem Adapter.** Lesepfad (project_assignments, account_assignments, cost_centers) und Schreibpfad (expenses) teilen Postgres-Instanz und Sitzungskontext — der Adapter kann in einer Transaktion gegenlesen, was er geschrieben hat, und die Testabdeckung wird trivial.
|
||
|
|
- **Kein externer Vertrauensanker.** Keine externen Tokens, keine externe Replay-Tabelle, keine SM59-Rotation in Runde 1. Jede Komponente läuft in unserem Cluster.
|
||
|
|
- **Lieferbar in Wochen, nicht Monaten.** SAP-Integration (Option A) hat eigene Produktentscheidungen offen (Travel Management vs. Concur vs. kundeneigener FI-Prozess, siehe `docs/architecture/v1.1.md` 7.1). Diese Entscheidung können wir treffen, nachdem der Trust-Kern bewiesen ist.
|
||
|
|
|
||
|
|
Option C scheidet aus: ohne Datenquellen-Komponente in Runde 1 bleibt der parallele Lesepfad ungetestet, und Attestierungen mit `read_materials` sind der kryptografisch anspruchsvollere Teil.
|
||
|
|
|
||
|
|
## Konsequenzen
|
||
|
|
|
||
|
|
### Positive
|
||
|
|
|
||
|
|
- Phase 4 im Phasenplan hat einen klaren Scope mit einem einzigen Deployment (`expense-db-adapter`).
|
||
|
|
- Wir können den Adapter-Vertrag aus `docs/architecture/v1.1.md` 7.0 und 7a.0 an einer realen Komponente härten, bevor wir SAP (`sap_abap`) oder generische Webhooks angehen.
|
||
|
|
- Das Datenmodell der DB-App ist klein und publishable — es dient später als Referenz für Partner, die eine ähnliche Senke anbinden wollen.
|
||
|
|
|
||
|
|
### Negative / Trade-offs
|
||
|
|
|
||
|
|
- SAP-Buchung schiebt sich auf Phase 6. Bis dahin müssen Reisekosten entweder im Zweistromverfahren (DB-App parallel zu SAP, keine Freigabe-Automatisierung in SAP) oder manuell nachgebucht werden.
|
||
|
|
- Wir bauen ein Business-Datenmodell neben SAP auf, das wir später konsolidieren müssen. Risiko eines Doppelstammdatens; wird in späterer ADR adressiert.
|
||
|
|
|
||
|
|
### Folgearbeiten / Open Points
|
||
|
|
|
||
|
|
- ADR zur Rolle der DB-App gegenüber SAP (Spiegelung vs. zweite autoritative Quelle).
|
||
|
|
- ADR zur SAP-Buchungsschnittstelle (Travel Management vs. Concur vs. kundeneigener FI-Prozess), spätestens vor Phase-6-Start.
|
||
|
|
|
||
|
|
## Links
|
||
|
|
|
||
|
|
- `docs/architecture/v1.1.md` Abschnitte 7.2, 10, 12
|
||
|
|
- Thread auf [DEV-598](/BAS/issues/DEV-598)
|