mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
fb1c1ee4ce
meldestelle/docs/05_Backend/Multi_Tenant_Kurz.md
StefanMoCoAt dbe7c74a9c Document tenant-aware database schema, multi-tenant strategy, and API references: 
- Add database schema documentation: `Database_Schema_V1-V009.md` for tenant-isolated entities (`veranstaltungen`, `turniere`, `bewerbe`, etc.).
- Draft initial Kassa API reference: `Kassa_API.md` (status: DRAFT).
- Finalize Stammdaten API reference: `API_Uebersicht_Stammdaten.md` (status: ACTIVE).
- Summarize tenant isolation and multi-tenant strategy in `Multi_Tenant_Kurz.md`.
- Update `README.md` with links to new references. Mark B-2 roadmap tasks as partially complete.
2026-04-03 22:59:45 +02:00

1.4 KiB
Raw Blame History

type status owner last_update
Reference ACTIVE Lead Architect 2026-04-03

Tenant-Isolation & Multi‑Tenant (Kurzfassung)

Vollständige Entscheidung: ADR‑0021: Tenant‑Resolution‑Strategie (Schema‑per‑Tenant).

Kernaussagen

  • Eine Veranstaltung = ein Tenant = ein Datenbankschema (Schema‑per‑Tenant).
  • Requests tragen X-Event-Id; Backend validiert gegen control.tenants und schaltet das Schema je Request.
  • Flyway führt Migrationen je Tenant‑Schema aus (eigene flyway_schema_history).
  • Stammdaten (Reiter/Pferde/Vereine/Funktionäre) sind global und nicht tenant‑spezifisch; Entries/Kassa sind tenant‑lokal.

Umsetzung (Kurz)

  • Web‑Layer: TenantWebFilter (Spring) bzw. Plugin (Ktor) liest X-Event-Id und legt TenantContext ab.
  • Persistence: SCHEMA‑Multitenancy (SET search_path) oder Hibernate‑MultiTenantConnectionProvider.
  • Registry: control.tenants(event_id, schema_name, status, db_url?, version, created_at).

Betroffene Bereiche

  • Datenmodell tenant‑lokal: veranstaltungen, turniere, bewerbe, abteilungen, teilnehmer_konten, turnier_kassa (siehe Datenbankschema).
  • Services: Der Entries‑Service arbeitet mandantenfähig; andere Services bleiben Single‑Tenant/global (vgl. Backend‑Roadmap).