meldestelle/docs/01_Architecture/MASTER_ROADMAP.md

type, status, owner, last_update

type	status	owner	last_update
Roadmap	ACTIVE	Lead Architect	2026-04-29

MASTER ROADMAP: Meldestelle

🏗️ [Lead Architect] | 29. 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.

• DDD-Analyse: 6 Bounded Contexts (SCS-Architektur) definiert.
• Terminologie: Veranstaltung ≠ Turnier gemäß ÖTO § 2 Abs. 1 festgelegt.
• Ubiquitous Language: Offizielle Domänen-Terminologie erstellt.

PHASE 2: Infrastruktur & ZNS-Importer (Prototyp) ✅

Status: Grundgerüst steht, Performance-Probleme bekannt.

• ZNS-Parser: Grundsätzliche Fähigkeit zum Parsen von ZNS-Daten (Reiter, Pferde, Vereine, Funktionäre).
• UI-Gerüst: Navigation und Dialog-Hüllen in Compose Desktop vorhanden.
• 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 (VERIFIKATION AUSSTEHEND)

Ziel: Ein stabiles, offline-fähiges technisches Fundament für die Desktop-App.

• OS-Pfad-Auflösung: Implementiert (Wartet auf Hardware-Test).
• Netzwerk-Interface-Binding: Implementiert (Wartet auf Hardware-Test).
• Geführte Discovery ("Radar-Modus"): Implementiert (Wartet auf Hardware-Test).
• Plan-USB Integration (UI): Implementiert (Wartet auf Hardware-Test).
• Offline-Lizenzierung (Konzept): Dokumentiert (ADR-0026).
• UX-Optimierung: Implementiert (Wartet auf Hardware-Test).
• Plan-USB Implementierung: Delta-Logik & AES-Export (Wartet auf Hardware-Test).
• PoC Verifikation: 🔴 OFFEN (Hardware-Test durch User erforderlich).

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.

Frühere (fiktive) Meilensteine anzeigen

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.

---

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/
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
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