meldestelle/docs/01_Architecture/MASTER_ROADMAP.md

type	status	owner	last_update
Roadmap	ACTIVE	Lead Architect	2026-03-25

MASTER ROADMAP: Meldestelle-Biest

🏗️ [Lead Architect] | 25. März 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.

Aktueller technischer Stand (25.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: ✅ DomReiter, DomNennung, DomNennungsTransfer, DomPferd, DomFunktionaer, DomVerein, 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	🟡 In Arbeit
competition-context	Bewerbe, Startlisten, Ergebnisse	P2	⬜ Geplant
event-management-context	Veranstaltung, Turnier, Ausschreibung	P2	⬜ Geplant
billing-context	Abrechnung, Kassa, Gebühren	P3	⬜ Geplant
identity-context	Auth, Rollen (Keycloak)	P3	⬜ Geplant
series-context	Cups, Serien, Meisterschaften	Phase 2+	🔵 Vorbereitet

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

PHASE 1: Documentation Cleanup ✅ ABGESCHLOSSEN

Ziel: Eine einzige, vertrauenswürdige Quelle der Wahrheit (SSOT) schaffen.

🧹 Agent: Curator

• Archivierung: Veraltete Docs (Cloudflare, GitHub-Workflows, alte Roadmaps) nach docs/_archive/ verschoben.
• Konsolidierung: Zora_System_Architektur.md als zentrale Infrastruktur-Doku etablieren.
• Struktur: docs/ Ordner aufräumen (unnötige Root-Files in Unterordner).
• Index: README.md im Root als Einstiegspunkt aktualisieren.

PHASE 2: Infrastructure Hardening ✅ ABGESCHLOSSEN

Ziel: Stabilisierung der neuen Self-Hosted Umgebung.

🐧 Agent: DevOps Engineer

• Keycloak Fix: Verbindungsprobleme innerhalb des Docker-Netzwerks behoben (Alias auth.mo-code.at).
• Backup Strategy: Automatisierte Backups für Gitea & Datenbanken auf Zora (config/scripts/backup.sh).
• Monitoring: Prometheus/Grafana Dashboard für Zora finalisiert (dc-ops.yaml).
• Deployment: Git-basiertes Deployment-Skript (config/scripts/deploy.sh) erstellt.

PHASE 3: Domain-Design & Ubiquitous Language ✅ ABGESCHLOSSEN

Ziel: Fachliche Grundlage für die Implementierung schaffen.

🏗️ Agent: Lead Architect

• DDD-Analyse: 6 Bounded Contexts (SCS-Architektur) definiert und priorisiert.
• Terminologie: Veranstaltung ≠ Turnier gemäß ÖTO § 2 Abs. 1 festgelegt (ADR).
• Design-Baseline: Vision_03 (Figma) als offizieller Design-Baseline festgelegt.
• Technologie: Desktop-First-Strategie mit KMP/Compose Desktop beschlossen.

📜 Agent: ÖTO/FEI Rulebook Expert

• Ubiquitous Language: Offizielle Domänen-Terminologie mit ÖTO-Referenzen erstellt.
• Abteilungs-Schwellenwerte: Alle Trennungs-Schwellenwerte (§ 39 + spartenspezifisch) dokumentiert. → docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md

👷 Agent: Backend Developer

• Enums: SparteE, TurnierkategorieE, VeranstaltungsTypE, LizenzKlasseE, NennungsStatusE, StartwunschE – ÖTO-konform.
• Domain-Modelle: DomReiter (actor-context), DomNennung, DomNennungsTransfer (registration-context).
• Modul: entries-domain als KMP-Modul aufgesetzt und in settings.gradle.kts registriert.

---

2. Aktuelle Phase

PHASE 4: MVP-Implementierung 🟡 IN ARBEIT

Ziel: Lauffähiger MVP für registration-context und actor-context (P1-Contexts).

🧐 Agent: QA Specialist

• Technical Debt: Idempotency-Plugin in masterdata wurde stabilisiert. → Fix: Unit-Test IdempotencyPluginTest ist wieder GRÜN. In-Flight Handling mit Timeouts und korrekter Pipeline-Phase (Render) gefixt. → Note: IdempotencyApiIntegrationTest bleibt vorerst @Disabled, da das Hochfahren des Spring-Contexts in der Testumgebung blockiert (unabhängig vom Plugin). → Task: Integration-Test Umgebung (Port-Binding/Server-Lifecycle) für masterdata-service untersuchen.

🏗️ Agent: Lead Architect

• ADRs vervollständigen: Bounded Context Mapping und Context Map dokumentieren. → docs/01_Architecture/adr/0014-bounded-context-mapping-de.md → docs/01_Architecture/adr/0015-context-map-de.md
• API-Design: Schnittstellen zwischen den Contexts definieren (Anti-Corruption Layer). → docs/01_Architecture/adr/0016-api-design-acl-de.md

👷 Agent: Backend Developer

• actor-context: Domain-Modelle für DomPferd, DomFunktionaer, DomVerein implementiert.
• registration-context: DomBewerb, DomAbteilung, DomStartliste implementiert.
• event-management-context: DomVeranstaltung, DomTurnier, DomAusschreibung implementiert.
• Persistenz: Repository-Interfaces und erste DB-Migrationen (Flyway/Liquibase).
• API: REST-Endpunkte für Nennungs-Workflow (Kern-Use-Cases).

🎨 Agent: Frontend Expert

• KMP/Compose Desktop: Projektstruktur aufgesetzt (frontend/shells/meldestelle-desktop).
• Navigation: Sidebar-Navigation gemäß Vision_03 implementiert (Veranstaltungen, Reiter, Pferde, Funktionäre, Meisterschaften, Cups).
• Nennungs-Screen: TurnierDetailScreen integriert NennungsMaske aus nennung-feature (Bewerbe-Tab ⭐).

📜 Agent: ÖTO/FEI Rulebook Expert

• Voltigieren (CVN): Abteilungs-Trennungsregeln aus B-Teil § 400 ff. ausgewertet (offene Frage #3 teilweise geklärt). → B IV enthält keine eigenen Regeln – verweist auf OEPS-Reglement CVN. § 39 Abs. 1 gilt nicht für CVN. § 39 Abs. 2 (> 80 Starter) gilt als Fallback. → docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md (Abschnitt 2.6)
• Fahren (CAN): Starter-Schwellenwerte jenseits der Reitertreffen-Regel geklärt (offene Frage #4 teilweise geklärt). → B VII enthält keine eigenen Regeln – verweist auf OEPS-Reglement „Turnierordnung für Gespanne". § 39 Abs. 1 gilt nicht für CAN. § 39 Abs. 2 (> 80 Starter) gilt als Fallback. Einzige gesicherte Lizenzregel: § 850 Abs. 9 (F1+ bei Fahrertreffen). → docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md (Abschnitt 2.5)
• Warn-Logik: Spezifikation der competition-context Warn-Logik für Abteilungs-Schwellenwerte. → docs/03_Domain/02_Reference/OETO_Regelwerk/Warn-Logik-Spezifikation-competition-context.md

🧹 Agent: Curator & Lead Architect (ZNS-Importer)

• ZNS-Importer (MVP) – Phase 1 & 2: core:zns-parser (KMP), ZnsLegacyParsers (alle 4 Dateitypen, CP850), ZnsImportService (Orchestrator, ZIP in-memory, Upsert), Unit-Tests grün. → Detaillierte Planung: docs/01_Architecture/Roadmap_ZNS_Importer.md
• Backend-Infrastruktur & CP850 Parser (Phase 1 – Parser/Modul)
• Domain-Mapping & Upsert in DB (Phase 2)
• REST-API & Job-Management (Phase 1 – Controller/Job-Registry)
• Frontend-Integration mit File-Picker & Status-Polling (Phase 3)

---

3. Geplante Phasen

PHASE 5: P2-Contexts & Integration ⬜ GEPLANT

Ziel: competition-context und event-management-context implementieren.

• competition-context: Bewerbe, Startlisten, Ergebnisse, Abteilungs-Warn-Logik.
• event-management-context: Veranstaltungs- und Turnier-Verwaltung, Ausschreibungs-Generator.
• ZNS-Integration: Schnittstelle zum Zentralen Nennungs-System (A-Satz / B-Satz).
• Offline-Sync: Offline-First-Strategie für Desktop-App implementieren.

PHASE 6: P3-Contexts & Billing ⬜ GEPLANT

Ziel: billing-context und identity-context implementieren.

• billing-context: Gebührenberechnung, Kassa, Abrechnung.
• identity-context: Rollen-Modell (TBA, Veranstalter, Richter etc.) mit Keycloak.
• Reporting: Startlisten- und Ergebnislisten-Druck (PDF).

PHASE 7: Series-Context & Erweiterungen 🔵 PHASE 2+

Ziel: Cups, Serien und Meisterschaften mit konfigurierbaren Reglements.

• series-context: Pluggable Berechnungsmodell, konfigurierbare Paar-Bindung.
• Web-Portal: Shared Module aus Desktop-App extrahieren → Web-Portal aufbauen.
• Mobile: KMP-Sharing auf Android/iOS ausweiten.

---

4. Wichtige Architektur-Entscheidungen (ADRs)

#	Entscheidung	Status	Dokument
1	Vision_03 = Design-Baseline	✅	Session Log 2026-03-24
2	Desktop-First mit KMP/Compose Desktop	✅	ADR-0009
3	Veranstaltung ≠ Turnier (ÖTO § 2 Abs. 1)	✅	Ubiquitous Language
4	6 Bounded Contexts als SCS-Architektur	✅	Session Log 2026-03-24
5	series-context ist Phase 2+ (Architektur vorbereitet)	✅	Session Log 2026-03-24
6	Cups/Serien benötigen konfigurierbare Reglements	✅	Session Log 2026-03-24
7	Warn-Logik statt harter Fehler (Override-Event)	✅	Abteilungs-Schwellenwerte.md
8	6 Bounded Contexts: Mapping & Aggregate Roots	✅	ADR-0014
9	Context Map: Integration Patterns & ACL-Strategie	✅	ADR-0015
10	API-Design & ACL: Ports, DTOs, REST-Endpunkte, Domain Events	✅	ADR-0016

---

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