2.9 KiB
2.9 KiB
| type | status | owner | last_update | sources | ||
|---|---|---|---|---|---|---|
| Architecture | ACTIVE | 🏗️ Lead Architect & 🧹 Curator | 2026-04-02 |
|
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:
Veranstaltungist die Root. Kassen und TeilnehmerKonten sind auf Event‑Ebene verankert. - Zahlvorgänge können mehrere Rechnungen/Belege aus verschiedenen Turnieren derselben Veranstaltung ausgleichen.