Migrate frontend navigation to V3: archive Navigation V2, implement updated screen-tree and back-stack rules, and adapt documentation for startable MVP flow.

2026-04-02 20:09:22 +02:00
parent 8b40a0624b
commit b787504474
10 changed files with 563 additions and 21 deletions
@@ -0,0 +1,66 @@
+---
+type: Architecture
+status: ACTIVE
+owner: 🏗️ Lead Architect & 🧹 Curator
+last_update: 2026-04-02
+sources:
+  - docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md
+  - Domain Workshop 2026-03-24
+---
+
+# Tenant‑Konzept: „Eine Veranstaltung = eine Datenbank“ (in einfacher Sprache)
+
+Kurz gesagt: Jede Veranstaltung bekommt ihre eigene kleine Datenbank. So bleiben Daten sauber getrennt, und die Meldestelle kann offline sicher arbeiten, ohne andere Veranstaltungen zu berühren.
+
+---
+
+## 1. Warum machen wir das?
+
+- Sicherheit und Ordnung: Was zu Veranstaltung A gehört, landet nicht aus Versehen bei Veranstaltung B.
+- Offline‑Tauglichkeit: Eine Datenbank pro Veranstaltung ist klein, lokal und schnell zu sichern/verteilen.
+- Einfache Abrechnung: Die Veranstaltungs‑Kassa und die TeilnehmerKonten sind klar auf Event‑Ebene definiert.
+
+---
+
+## 2. Wie wird bestimmt, welche Datenbank benutzt wird?
+
+Siehe Architektur‑Entscheidung (ADR‑0021):
+
+- Datei: `docs/01_Architecture/adr/0021-tenant-resolution-strategy-de.md`
+- Kerngedanke: Die App leitet aus dem aktuellen „Arbeitskontext“ (gewählte Veranstaltung) den Tenant ab. Alle Lese/Schreib‑Operationen gehen automatisch in die richtige Event‑Datenbank.
+
+---
+
+## 3. Auswirkungen im Überblick
+
+### a) Datenbank‑Schema (Backend)
+
+- Pro Veranstaltung ein eigenes Schema/Datei (z. B. `event-{eventId}.db`).
+- Tabellen wiederholen sich je Veranstaltung (z. B. `turniere`, `bewerbe`, `abteilungen`, `startlisten`, `kassa_belege`).
+- Keine Vermischung zwischen Veranstaltungen. Für Auswertungen über mehrere Veranstaltungen braucht es einen Aggregations‑Prozess.
+
+### b) API‑Design
+
+- Jeder Request enthält implizit oder explizit den Event‑Kontext (Header, Pfad oder Session‑Scope).
+- Schreib‑Operationen validieren, dass die Ziel‑IDs (Turnier, Bewerb, Abteilung) zur aktuellen Veranstaltung gehören.
+- Export/Import: Datenpakete sind pro Veranstaltung abgegrenzt (leichte Weitergabe an Verband oder andere Systeme).
+
+### c) Frontend (Navigation & State)
+
+- Beim Eintritt in eine Veranstaltung wird der Tenant gesetzt; alle folgenden Screens arbeiten innerhalb dieses Kontexts.
+- Wechsel der Veranstaltung leert relevante Caches und setzt den Back‑Stack definiertermaßen zurück (→ Navigation V2).
+- Multi‑Turnier‑Fälle innerhalb EINER Veranstaltung bleiben möglich (Turnierkassa je Turnier, Konsolidierung in Veranstaltungs‑Kassa).
+
+---
+
+## 4. Grenzen & Trade‑offs
+
+- Cross‑Event‑Suche/Auswertung erfordert separate Aggregation (bewusste Entscheidung zugunsten Offline‑First und Sicherheit).
+- Datenmigration (z. B. Zusammenlegen/Teilen von Veranstaltungen) braucht Tools/Assistenten.
+
+---
+
+## 5. Beziehung zur Domäne
+
+- Ubiquitous Language: `Veranstaltung` ist die Root. Kassen und TeilnehmerKonten sind auf Event‑Ebene verankert.
+- Zahlvorgänge können mehrere Rechnungen/Belege aus verschiedenen Turnieren derselben Veranstaltung ausgleichen.