docs(adr): ZNS-First Enrollment Pattern und ZNS-Light Strategie dokumentiert

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-16 12:40:51 +02:00
parent eb0fac5989
commit 10f9e82718
2 changed files with 81 additions and 0 deletions
@@ -0,0 +1,32 @@
+# ADR-0023: ZNS-First Enrollment Pattern (ZNS-Light)
+
+## Status
+
+Akzeptiert
+
+## Kontext
+
+Die Anlage einer neuen pferdesportlichen Veranstaltung erfordert eine solide Datenbasis (ZNS-Daten für Vereine, Reiter,
+Pferde etc.). Der bisherige Ansatz (erst Veranstaltung anlegen, dann Daten importieren) führte zu Konsistenz-Problemen,
+da der Veranstalter (Verein) oft bereits im ZNS-Stamm existiert.
+Darüber hinaus dauert ein vollständiger ZNS-Import aufgrund der Datenmenge (~20 Minuten) zu lange, um ihn in einen
+Echtzeit-Wizard einzubauen.
+
+## Entscheidung
+
+Wir führen das **ZNS-First Enrollment Pattern** ein:
+
+1. Der Wizard beginnt mit dem Import der ZNS-Daten.
+2. Um Performance sicherzustellen, wird im ersten Schritt ein **"ZNS-Light" Import** durchgeführt (nur `VEREIN01.dat`
+   und `LIZENZ01.dat`).
+3. Die importierten Daten werden in einer **Staging-Area (Backend-Buffer)** temporär vorgehalten.
+4. Erst bei der Finalisierung der Veranstaltungs-Metadaten wird die UUID generiert und die mandantenfähige Datenbank
+   provisioniert.
+5. Massive Datensätze (Pferde, Richter) werden **lazy** nachgeladen.
+
+## Konsequenzen
+
+* **Positiv:** Höhere Datenqualität (Veranstalter wird sofort korrekt gematcht).
+* **Positiv:** Minimale Wartezeit im Wizard durch selektiven Import.
+* **Negativ:** Backend muss Staging-Funktionalität für unfertige Wizards bereitstellen.
+* **Frontend:** Der `VeranstaltungNeuScreen` wird zum zentralen Orchestrator dieses 3-Schritt-Flows.