158 lines
8.3 KiB
Markdown
158 lines
8.3 KiB
Markdown
---
|
|
type: Roadmap
|
|
status: ACTIVE
|
|
owner: Lead Architect
|
|
last_update: 2026-04-21
|
|
---
|
|
|
|
# MASTER ROADMAP: Meldestelle
|
|
|
|
🏗️ **[Lead Architect]** | 20. April 2026
|
|
|
|
**Strategisches Ziel:**
|
|
Entwicklung einer ÖTO-konformen, offline-fähigen Turnier-Meldestelle als Compose Desktop App (KMP).
|
|
Vollständige Self-Hosted Infrastruktur (Gitea, Pangolin, Zora). Datensouveränität, Offline-First, saubere Wissensbasis.
|
|
|
|
**Produktfokus:**
|
|
- Desktop-App ist der primäre Client (Compose Desktop, KMP) — „Desktop-First“ gilt für UX und Architektur.
|
|
- Offline-First Betrieb mit lokaler Persistenz und opportunistischer Synchronisation.
|
|
|
|
**Aktueller technischer Stand (30.03.2026):**
|
|
* **Infrastruktur:** ✅ "Zora" (MS-R1, ARM64) ist live. Gitea & Registry laufen.
|
|
* **Networking:** ✅ Pangolin Tunnel ersetzt Cloudflare.
|
|
* **CI/CD:** ✅ Gitea Actions mit ARM64-Runner (VM 102) aktiv. Docker-Publish Pipeline grün.
|
|
* **Code-Basis:** ✅ Backend (Java 25 / Spring Boot / Kotlin), Frontend (KMP/Compose Desktop).
|
|
* **Domain-Design:** ✅ 6 Bounded Contexts (SCS-Architektur) definiert. Ubiquitous Language erstellt.
|
|
* **Domain-Modelle:** ✅ `Reiter`, `DomNennung`, `DomNennungsTransfer`, `Pferd`, `Funktionaer`, `Verein`,
|
|
`DomBewerb`, `DomAbteilung`, `DomStartliste`, `DomVeranstaltung`, `DomTurnier`, `DomAusschreibung` implementiert.
|
|
Enums ÖTO-konform.
|
|
* **Dokumentation:** ✅ Konsolidiert. ÖTO-Regelwerk-Referenzen (Abteilungs-Schwellenwerte) dokumentiert.
|
|
|
|
---
|
|
|
|
## Architektur-Übersicht: 6 Bounded Contexts (SCS)
|
|
|
|
Das System ist in **6 Self-Contained Systems (SCS)** aufgeteilt, die fachlich voneinander getrennt sind
|
|
und über definierte Schnittstellen kommunizieren.
|
|
|
|
| SCS | Kontext | Priorität | Status |
|
|
|----------------------------|---------------------------------------|-----------|--------------|
|
|
| `registration-context` | Nennungs-Workflow (Herzstück) | **P1** | 🔵 In Arbeit |
|
|
| `actor-context` | Reiter, Pferde, Funktionäre, ZNS | **P1** | 🟡 MVP |
|
|
| `competition-context` | Bewerbe, Startlisten, Ergebnisse | **P2** | 🔵 In Arbeit |
|
|
| `event-management-context` | Veranstaltung, Turnier, Ausschreibung | **P2** | 🔵 In Arbeit |
|
|
| `series-context` | Cups, Serien, Meisterschaften | Phase 2+ | 🔵 In Arbeit |
|
|
| `billing-context` | Abrechnung, Kassa, Gebühren | **P3** | 🔵 In Arbeit |
|
|
| `identity-context` | Auth, Rollen (Keycloak) | **P3** | 🟡 MVP |
|
|
|
|
> **Hinweis `series-context`:** Ist Phase 2+, aber die Architektur ist von Anfang an vorbereitet.
|
|
> Cups/Serien/Meisterschaften benötigen eigene, konfigurierbare Reglements (kein Hard-Coding).
|
|
> Pluggable Berechnungsmodell und konfigurierbare Paar-Bindung (Reiter+Pferd vs. nur Reiter) erforderlich.
|
|
|
|
---
|
|
|
|
## 1. Abgeschlossene Phasen (Verifiziert)
|
|
|
|
### PHASE 1: Domain-Design & Ubiquitous Language ✅
|
|
|
|
*Status: Fachliche Grundlage vorhanden.*
|
|
|
|
* [x] **DDD-Analyse:** 6 Bounded Contexts (SCS-Architektur) definiert.
|
|
* [x] **Terminologie:** `Veranstaltung` ≠ `Turnier` gemäß ÖTO § 2 Abs. 1 festgelegt.
|
|
* [x] **Ubiquitous Language:** Offizielle Domänen-Terminologie erstellt.
|
|
|
|
### PHASE 2: Infrastruktur & ZNS-Importer (Prototyp) ✅
|
|
|
|
*Status: Grundgerüst steht, Performance-Probleme bekannt.*
|
|
|
|
* [x] **ZNS-Parser:** Grundsätzliche Fähigkeit zum Parsen von ZNS-Daten (Reiter, Pferde, Vereine, Funktionäre).
|
|
* [x] **UI-Gerüst:** Navigation und Dialog-Hüllen in Compose Desktop vorhanden.
|
|
* [x] **Plan-B:** Rudimentärer Mail-Service für Nennungs-Versand (funktional).
|
|
|
|
---
|
|
|
|
## 2. Der neue Weg: Fachliche Realität (Roadmap 2026)
|
|
|
|
Fokus: Physische Implementierung der Turnier-Hierarchie.
|
|
|
|
### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) 🔵 IN ARBEIT
|
|
|
|
*Ziel: Veranstaltung -> Turnier -> Bewerb/Abteilung physisch anlegen und speichern.*
|
|
|
|
* [ ] **Persistenz-Layer:** Implementierung der lokalen Speicherung für alle Ebenen der Hierarchie.
|
|
* [ ] **Turnier-Wizard (Echt):** Umstellung des Wizards von `println`-Dummies auf echte Datenbank-Transaktionen.
|
|
* [ ] **Validierung:** Sicherstellen, dass Pflichtfelder (Turniernummer, Sparte) korrekt erfasst werden.
|
|
|
|
### MEILENSTEIN 2: ZNS-Performance & Daten-Qualität (Prio 2)
|
|
|
|
*Ziel: Import der ZNS.zip in < 2 Minuten statt 30+ Minuten.*
|
|
|
|
* [ ] **Batch-Processing:** Umstellung des `ZnsImportService` auf Batch-Inserts (JDBC/Exposed).
|
|
* [ ] **Fortschritts-Anzeige:** Reale Rückmeldung über den Import-Status in der UI.
|
|
|
|
### MEILENSTEIN 3: Richtverfahren & Bewerbs-Konfiguration (Prio 3)
|
|
|
|
*Ziel: Bewerbe mit fachlich korrekten Regeln (ÖTO) anlegen.*
|
|
|
|
* [ ] **Richtverfahren-Engine:** Validierungslogik für verschiedene Richtverfahren (Fehler/Zeit, Wertnoten).
|
|
* [ ] **Abteilungs-Logik:** Automatische Teilungsvorschläge gemäß ÖTO § 39.
|
|
|
|
---
|
|
|
|
## 3. Zukünftige Module (Status: Geplant / Vision)
|
|
|
|
*Diese Module existieren derzeit nur als Konzepte oder leere Hüllen.*
|
|
|
|
* **Nennungs-Management:** Erfassung von Nennungen gegen den ZNS-Datenbestand.
|
|
* **Zeitplan:** Dynamische Zeitplanung (Drag & Drop).
|
|
* **Ergebnisse:** Erfassung von Wertungen und Platzierungsberechnung.
|
|
* **Abrechnung:** Vollständiger `billing-context`.
|
|
|
|
---
|
|
|
|
## 4. Archiv der fiktiven Meilensteine (Reality-Check am 28.04.2026)
|
|
|
|
*Die folgenden Einträge wurden in früheren Sitzungen als "Abgeschlossen" markiert, entsprachen aber nicht dem realen
|
|
Code-Stand.*
|
|
|
|
<details>
|
|
<summary>Frühere (fiktive) Meilensteine anzeigen</summary>
|
|
|
|
### PHASE 4: MVP-Implementierung (Früherer Status: Abgeschlossen)
|
|
|
|
* [ ] ZNS-Import Optimierung (Batching) -> In MEILENSTEIN 2 verschoben.
|
|
* [ ] `event-management-context` Implementierung -> In MEILENSTEIN 1 verschoben.
|
|
|
|
### PHASE 5-13 (Früherer Status: Abgeschlossen/In Arbeit)
|
|
|
|
* [ ] `competition-context` (Bewerbe, Startlisten) -> Fachlogik fehlt weitgehend.
|
|
* [ ] `billing-context` (Abrechnung) -> Nur Infrastruktur-Hülle vorhanden.
|
|
* [ ] `results-service` -> Geschäftslogik fehlt.
|
|
|
|
</details>
|
|
|
|
---
|
|
|
|
|
|
## 5. Wichtige Referenzen
|
|
|
|
| Dokument | Pfad |
|
|
|---------------------------|----------------------------------------------------------------------------------------------|
|
|
| Ubiquitous Language | `docs/03_Domain/01_Glossary/Ubiquitous_Language.md` |
|
|
| Abteilungs-Schwellenwerte | `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` |
|
|
| Warn-Logik-Spezifikation | `docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md` |
|
|
| Session Log (DDD) | `docs/99_Journal/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md` |
|
|
| Infrastruktur | `docs/07_Infrastructure/Zora_System_Architektur.md` |
|
|
| Deployment Guide | `docs/07_Infrastructure/Guides/Setup_Git_Deployment_Zora.md` |
|
|
| Backup Guide | `docs/07_Infrastructure/Guides/Setup_Backup_Zora.md` |
|
|
| CI/CD | `.gitea/workflows/docker-publish.yaml` |
|
|
| Agent Playbooks | `docs/04_Agents/Playbooks/` |
|
|
| ADR-Verzeichnis | `docs/01_Architecture/adr/` |
|
|
| ZNS-Importer Roadmap | `docs/01_Architecture/Roadmap_ZNS_Importer.md` |
|
|
| Masterdata Roadmap | `backend/services/masterdata/docs/ROADMAP.md` |
|
|
| Masterdata Changelog | `backend/services/masterdata/docs/CHANGELOG.md` |
|
|
| Masterdata Operations | `backend/services/masterdata/docs/runbooks/masterdata-ops.md` |
|
|
| Zeitplan-Optimierung | `docs/01_Architecture/konzept-zeitplan-optimierung-de.md` |
|
|
| Parcoursbesichtigung-Rulebook | `docs/01_Architecture/rulebook-check-parcoursbesichtigung-de.md` |
|
|
| Status-Automat-Nennungen | `docs/01_Architecture/status-automat-nennungen-de.md` |
|