32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
---
|
||
type: ADR
|
||
status: PROPOSED
|
||
owner: Lead Architect
|
||
date: 2026-04-21
|
||
---
|
||
|
||
# ADR-0027 — Draft-Domain & Delta‑Sync (Versionierung, Konfliktlösung, Idempotenz)
|
||
|
||
## Kontext
|
||
- Offline‑First verlangt lokale Drafts, Resume‑Fähigkeit und robuste Synchronisation bei instabiler Konnektivität.
|
||
- Heute: kein einheitliches Draft‑Modell, keine standardisierte Schritt‑weise Speicherung.
|
||
|
||
## Entscheidung
|
||
- Einführung einer Draft‑Domain mit Version/ETag und Schritt‑Patchs:
|
||
- `POST /api/events/drafts` (idempotent über Idempotency‑Key) erstellt/vereinigt Drafts.
|
||
- `PATCH /api/events/drafts/{id}` speichert step‑weise Deltas (nur geänderte Felder seit `version`).
|
||
- `POST /api/events` finalisiert (Server‑Validierung, Erstellung `veranstaltungId`).
|
||
- Client Offline‑Queue mit Retry/Backoff; Konflikte als nicht‑blockierende Hinweise.
|
||
|
||
## Konsequenzen
|
||
- Reproduzierbare, idempotente Speicherung; geringere Payloads; klare Konfliktauflösung.
|
||
- Erfordert Versionierung im DraftStore und Migrationspfade bei Flow‑Änderungen (`flowVersion`).
|
||
|
||
## Umsetzung
|
||
- Frontend: DraftStore (Autosave `onLeave`), Delta‑Builder je Step, Queue mit Idempotency‑Key.
|
||
- Backend: Versionsverwaltung, If‑Match/ETag Unterstützung, Conflict‑Detect (409) mit Merge‑Hinweisen.
|
||
|
||
## Verweise
|
||
- Roadmap‑Abschnitt: `docs/01_Architecture/MASTER_ROADMAP.md#3-initiative-wizard-orchestrator--offline-drafts-q2q3-2026`
|
||
- Contracts: folgen nach API‑Skizzierung (`contracts/` Verzeichnis)
|