docs(adr): ZNS-First Enrollment Pattern und ZNS-Light Strategie dokumentiert
Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -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.
|
||||||
@@ -0,0 +1,49 @@
|
|||||||
|
# Journal-Eintrag: 2026-04-16 - ZNS-First Wizard & ZNS-Light Strategie
|
||||||
|
|
||||||
|
## 🏗️ [Lead Architect] & 👷 [Backend Developer] & 🖌️ [UI/UX Designer]
|
||||||
|
|
||||||
|
### 🎯 Zielsetzung
|
||||||
|
|
||||||
|
Lösung des Henne-Ei-Problems bei der Veranstaltungs-Anlage durch Invertierung des Workflows. Sicherstellung einer hohen
|
||||||
|
Performance (Speed over Animation) durch selektiven ZNS-Import.
|
||||||
|
|
||||||
|
### 🛠️ Getroffene Entscheidungen
|
||||||
|
|
||||||
|
#### 1. Der "ZNS-First Enrollment" Workflow (3-Schritt-Wizard)
|
||||||
|
|
||||||
|
Der Wizard für eine neue Veranstaltung wird radikal umgebaut, um die Datenintegrität von Anfang an sicherzustellen:
|
||||||
|
|
||||||
|
* **Schritt 1: ZNS-Basis & Veranstalter**
|
||||||
|
* Upload der `ZNS.zip`.
|
||||||
|
* Sofortiger Import der `VEREIN01.dat` (Vereine) und `LIZENZ01.dat` (Personen).
|
||||||
|
* Auswahl des Veranstalters aus den importierten Daten (oder manuelle Neuanlage).
|
||||||
|
* **Schritt 2: Meta-Daten & DB-Initialisierung**
|
||||||
|
* Eingabe von Titel, Datum (von-bis) und Ort.
|
||||||
|
* Nach Validierung: Generierung der `veranstaltungId` (UUID).
|
||||||
|
* Provisionierung der spezifischen Veranstaltungs-Datenbank und Transfer der ZNS-Light-Daten aus dem Staging-Buffer.
|
||||||
|
* **Schritt 3: Fachlicher Typ**
|
||||||
|
* Wahl der Veranstaltungsart (derzeit "Turnier").
|
||||||
|
* Weiterleitung zum Turnier-Cockpit.
|
||||||
|
|
||||||
|
#### 2. "ZNS-Light" Performance-Strategie
|
||||||
|
|
||||||
|
Um die Wartezeit beim ersten Import von ~20 Minuten auf wenige Sekunden/Minuten zu reduzieren:
|
||||||
|
|
||||||
|
* **Light-Modus:** Nur `VEREIN01` und `LIZENZ01` werden im Wizard geladen.
|
||||||
|
* **Lazy-Modus:** Die massiven Datenmengen von `PFERDE01` und `RICHT01` werden erst im Turnier-Setup oder bei Bedarf im
|
||||||
|
Hintergrund geladen.
|
||||||
|
|
||||||
|
#### 3. Frontend-Konsolidierung (Single Source of Truth)
|
||||||
|
|
||||||
|
* Alle Entwürfe (V1/V2) werden im `VeranstaltungNeuScreen.kt` zusammengeführt.
|
||||||
|
* Redundante Screens wie der separate `StammdatenImportScreen` werden als Komponente in den Wizard integriert.
|
||||||
|
|
||||||
|
### 🚀 Nächste Schritte (für die neue Session)
|
||||||
|
|
||||||
|
1. **Backend-Staging-Buffer:** Implementierung der temporären Speicherung der ZNS-Light-Daten während des Wizards.
|
||||||
|
2. **Wizard-Implementation:** Umsetzung des 3-Schritt-Flows im `VeranstaltungNeuScreen.kt`.
|
||||||
|
3. **API-Erweiterung:** `ZnsImportService` um den `mode=LIGHT` Parameter erweitern.
|
||||||
|
|
||||||
|
---
|
||||||
|
🧹 **[Curator]**: Dieses Dokument dient als Übergabeprotokoll für die nächste Session. Alle fachlichen und technischen
|
||||||
|
Parameter sind hiermit fixiert.
|
||||||
Reference in New Issue
Block a user