67 lines
2.9 KiB
Markdown
67 lines
2.9 KiB
Markdown
---
|
||
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.
|