mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7480aed4d1
meldestelle/docs/01_Architecture/MASTER_ROADMAP.md
Stefan Mogeritsch 0aa1a1b9b7 feat(entries+time-scheduling): add support for automatic breaks and inspection type configurations 
- **Domain Enhancements:**
  - Introduced `PausenKonfiguration` and `BesichtigungsBlock` entities to handle automatic breaks and inspection scheduling.
  - Added `BesichtigungsTypE` enum for inspection types (`ZU_FUSS`, `ZU_PFERD`).
  - Updated `Bewerb` and `Abteilung` models to include pause and inspection type fields.

- **Service Updates:**
  - Enhanced `StartlistenService` to calculate start times, accounting for breaks and inspection buffers.
  - Extended `BewerbService` to support patchable time scheduling via new `updateZeitplan` API.

- **Persistence Changes:**
  - Updated tables (`BewerbTable`, `AbteilungTable`) to persist break configurations and inspection types.
  - Implemented repository mappings to include these new fields.

- **Testing:**
  - Introduced `BewerbeZeitplanIntegrationTest` to validate new scheduling behaviors, including automatic pauses and inspection handling.

- **Documentation:**
  - Added rulebook and conceptual documents for inspection and scheduling logic in `docs/01_Architecture/`.
2026-04-11 12:21:42 +02:00

19 KiB
Raw Blame History

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

MASTER ROADMAP: Meldestelle-Biest

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

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 ✅ Fertig
actor-context Reiter, Pferde, Funktionäre, ZNS P1 ✅ Fertig
competition-context Bewerbe, Startlisten, Ergebnisse P2 ✅ Fertig
event-management-context Veranstaltung, Turnier, Ausschreibung P2 ✅ Fertig
billing-context Abrechnung, Kassa, Gebühren P3 ✅ Fertig
identity-context Auth, Rollen (Keycloak) P3 ✅ Fertig
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 ✅ ABGESCHLOSSEN

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

🧐 Agent: QA Specialist

  • Actor Context Stabilization: Funktionär-Datenmodell (Richter/Parcoursbauer) auf professionelle Master-Daten-Referenzierung umgestellt und mit Reiter-Daten verknüpft (Import-Idempotenz via satzNummer). Redundante Kontakt-/Adressdaten entfernt. Alle ZNS-Import-Tests (9/9) stabilisiert und verwaiste Parser-Reste entfernt.
  • Masterdata Standardization: Bereinigung und Standardisierung der Masterdaten-Tabellen (Mehrzahl-Konvention: bundeslaender, funktionaers_qualifikationen, reit_lizenzen, turnier_klassen).
  • ÖTO Data Seeding: Umfassende Seeder für Funktionärs-Qualifikationen, Turnierklassen und Turnier-Sparten gemäß ÖTO implementiert. Einführung der Tabelle turnier_sparten.
  • ZNS-Import Optimization: Automatische Verknüpfung von Funktionären mit Reitern (Reihenfolge: VEREIN -> LIZENZ -> PFERDE -> RICHT). ZnsImportService für sequentielle Imports in Tests gehärtet.
  • Service Stability: Port-Konflikt des masterdata-service (Spring Management Port 8081 vs. Gateway) durch Umzug auf Port 8086 und explizite Bind-Adressen (Spring: 127.0.0.1, Ktor: 0.0.0.0) dauerhaft gelöst.
  • Documentation: CHANGELOG.md aktualisiert und Port-Konfiguration in application.yml dokumentiert. → 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
  • ÖTO-Validation-Seeds: Seed-Daten für Lizenz-Matrix und Altersklassen finalisiert (V008).

👷 Agent: Backend Developer

  • ZNS-Importer: Support für Richter-Import (RICHT01.DAT) und Reiter-Refactoring (LIZENZ01.DAT) vervollständigt. ✓
  • Masterdata: Qualifikations-System und Personen-Referenzen (Vereine, Bundesländer, Nationen) stabilisiert (Consul & MasterdataSeeder). ✓
  • Infrastruktur: Service-Discovery (Consul) für alle Microservices (incl. Masterdata) aktiviert.
  • Infrastruktur: Bean-Definitionen und Dependency-Injection im zns-import-service bereinigt.
  • Database: Initialisierung der Funktionärs-Tabellen stabilisiert (PSQLException Fix).
  • actor-context: Domain-Modelle für Pferd, Funktionaer, Verein 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).
  • Infrastruktur-Stabilisierung: Kompilierfehler in masterdata-infrastructure behoben.
  • Identity-Schnittstellen: Endpunkte für ZNS-Linking über identity-service bereitgestellt.

🎨 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. Aktuelle Phase

PHASE 5: P2-Contexts & Integration ✅ ABGESCHLOSSEN

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 ✅ ABGESCHLOSSEN

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).

4. Geplante Phasen

PHASE 7: Desktop-Vernetzung & Zentrale Verwaltung ✅ ABGESCHLOSSEN

Ziel: LAN-Kommunikation Vorbereitung und Etablierung der "Veranstaltung-Verwaltung" als zentrale Schaltstelle.

  • Zentrale Verwaltung: Etablierung der Veranstaltung-Verwaltung (Zentrale) als administratives Cockpit.
  • Navigation: Implementierung eines Back-Stack-Systems für intelligente "Zurück"-Navigation.
  • Domänen-Synchronisation: Anpassung der Frontend-Stores an die Backend-Masterdata-Modelle (Reiter, Pferde, Vereine, Funktionäre).
  • ZNS-Integration (Frontend): ZNS-Importer in die Zentrale integriert; Konzept "Globaler Pool -> Lokale Synchronisation" gefestigt.
  • Terminologie: UI-weit Umstellung von "Event" auf "Veranstaltung" (ÖTO-konform).
  • Konzept: LAN-Discovery (mDNS) und Echtzeit-Sync (WebSockets) entworfen.
  • ADR: ADR-0020 (Lokale Netzwerk-Kommunikation) erstellt.

PHASE 8: Bewerbe-Management & Startlisten ✅ ABGESCHLOSSEN

Ziel: Fachliche Tiefe in den Turnieren (Import, Generierung, Zeitberechnung).

  • Konzept/ADR: LAN‑Sync (ADR‑0022) und Offline‑First Desktop↔Backend Konzept definiert und verlinkt.
  • Bewerbe-Import: Implementierung der Merge-Logik (ZNS-XML -> BewerbUiModel). ✓
  • Startlisten-Automatisierung: Generierung und Zeitberechnung (Pausen, Umbauzeiten). ✓
  • Discovery: Implementierung des mDNS-Service (JmDNS) für die Geräte-Suche. ✓
  • Transport: Aufbau der WebSocket-Infrastruktur für P2P-Sync (Ktor WebSockets, SyncManager). ✓
  • Offline-First Desktop↔Backend: Umsetzung gemäß Konzept „Offline-First Synchronisation (Desktop ↔ Backend)“ → docs/01_Architecture/konzept-offline-first-desktop-backend-de.md. ✓
  • Regelwerks-Validierung: Implementierung des strukturierten Abteilungs-Warnungssystems gemäß ÖTO § 39 inkl. UI-Integration. ✓

PHASE 9: Zeitplan-Optimierung & Protokollierung 🔵 IN ARBEIT

Ziel: Dynamische Zeitplan-Anpassungen, Protokollierung von Änderungen und Export-Funktionen.

  • Billing-Service: Initialisierung, Teilnehmer-Konten & Buchungs-Logik (v1). ✓
  • Entries-Integration: Automatische Buchung von Nenngeldern bei Nennungs-Abgabe. ✓
  • ZNS-Importer: Hardening & Integrationstests für Funktionärs-Updates. ✓
  • Konzept: Fachliches Konzept für Zeitplan-Optimierung (Drag & Drop) erstellt. ✓
  • Zeitplan: Dynamische Verschiebung von Bewerben (Drag & Drop im Kalender).
  • Protokoll: Implementierung eines Event-Logs für manuelle Eingriffe in Startlisten.
  • Export: Startlisten-Export für ZNS (XML-B-Satz).

PHASE 10: 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
11 Masterdata: Importer-Einbettung als Worker ✅ ADR-0017
12 Masterdata: Rule-Versionierung (Regulation-as-Data) ✅ ADR-0018
13 Masterdata: API-Schichten (REST vs. Ingestion) ✅ ADR-0019
14 Lokale Netzwerk-Kommunikation und Daten-Isolierung ✅ ADR-0020
15 Masterdata: Observability & Operations ✅ masterdata-ops.md, CHANGELOG
16 Tenant-Resolution: Schema-per-Tenant ✅ ADR-0021
17 LAN-Sync-Protokoll (Lamport-Uhren, Event-Sourcing Light) ✅ ADR-0022

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