179 lines
10 KiB
Markdown
179 lines
10 KiB
Markdown
---
|
|
type: Roadmap
|
|
status: ACTIVE
|
|
owner: Lead Architect
|
|
last_update: 2026-06-15
|
|
---
|
|
|
|
# MASTER ROADMAP: Meldestelle
|
|
|
|
🏗️ **[Lead Architect]** | 15. Juni 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 (15.06.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`, `Nennung`, `NennungsTransfer`, `Pferd`, `Funktionaer`, `Verein`,
|
|
`Bewerb`, `Abteilung`, `DomStartliste`, `Veranstaltung`, `Turnier`, `Ausschreibung` implementiert.
|
|
Enums ÖTO-konform.
|
|
* **Dokumentation:** 🧹 Sanierung abgeschlossen (5-Säulen-Struktur). Reality-Reset durchgeführt.
|
|
|
|
---
|
|
|
|
## 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 und technisches Onboarding.
|
|
|
|
### MEILENSTEIN 0: Technische Geräte-Initialisierung (Prio 1) 🚧 IN ARBEIT (STABILISIERUNG)
|
|
|
|
*Ziel: Ein stabiles, offline-fähiges technisches Fundament für die Desktop-App.*
|
|
|
|
* [x] **App-Icons (PNG/ICO):** Implementiert (Fix für Build-Fehler).
|
|
* [x] **Docker-Fix:** "services must be a mapping" behoben (dc-gui.yaml).
|
|
* [x] **Chat-Funktion (Desktop):** MVP implementiert (Navigation & UI).
|
|
* [x] **Geführte Discovery ("Zero-Config"):** Master-Namen statt IPs, "Wait-State" für Clients.
|
|
* [x] **Native FileDialogs:** Stabile Pfad-Auswahl für Plan-USB auf allen Systemen.
|
|
* [x] **Handshake-Feedback:** Visuelle Signalisierung des Verbindungsstatus (Grün/Rot).
|
|
* [x] **Client-Konfiguration:** Master kann nun Clients in der UI hinzufügen und bearbeiten.
|
|
* [x] **Master-UX:** Konfiguration beim Start nicht mehr zwangsgesperrt.
|
|
* [x] **Cross-Packaging (Conveyor):** Windows-Build auf Linux-CI ermöglicht (x64-Abhängigkeit identifiziert).
|
|
* [x] **Build-Performance:** WASM standardmäßig deaktiviert, um Desktop-Build-Zeiten zu reduzieren (11.05.2026).
|
|
* [ ] **PoC Verifikation:** 🔴 **BLOCKIERT** (Log 483: ARM64-Runner inkompatibel mit Conveyor-Binary; Workflow auf
|
|
manuell gesetzt).
|
|
|
|
### MEILENSTEIN 1: Die Basis-Hierarchie (Prio 1) ⚪ GEPLANT
|
|
|
|
*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/02_Domain/01_Glossary/Ubiquitous_Language.md` |
|
|
| Abteilungs-Schwellenwerte | `docs/02_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md` |
|
|
| Warn-Logik-Spezifikation | `docs/02_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md` |
|
|
| Session Log (DDD) | `docs/05_Governance/Journal/_archive/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md` |
|
|
| Infrastruktur | `docs/04_Operations/Infrastructure/Zora_System_Architektur.md` |
|
|
| Deployment Guide | `docs/04_Operations/Infrastructure/Guides/Setup_Git_Deployment_Zora.md` |
|
|
| Backup Guide | `docs/04_Operations/Infrastructure/Guides/Setup_Backup_Zora.md` |
|
|
| CI/CD | `.gitea/workflows/docker-publish.yaml` |
|
|
| Agent Playbooks | `docs/05_Governance/Agents/Playbooks/` |
|
|
| ADR-Verzeichnis | `docs/01_Architecture/adr/` |
|
|
| ADR-0025: Plan-USB | `docs/01_Architecture/adr/0025-plan-usb-offline-integritaet.md` |
|
|
| ADR-0026: Lizenzierung | `docs/01_Architecture/adr/0026-offline-lizenzierung-pay-per-event.md` |
|
|
| ADR-0027: Discovery | `docs/01_Architecture/adr/0027-netzwerk-discovery-interface-binding.md` |
|
|
| Docker-Fix: dc-gui.yaml | `dc-gui.yaml` |
|
|
| ZNS-Importer Roadmap | `docs/01_Architecture/Roadmaps/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/Concepts/konzept-zeitplan-optimierung-de.md` |
|
|
| Parcoursbesichtigung-Rulebook | `docs/01_Architecture/Concepts/rulebook-check-parcoursbesichtigung-de.md` |
|
|
| Status-Automat-Nennungen | `docs/01_Architecture/Concepts/status-automat-nennungen-de.md` |
|