StefanMoCoAt
beb20e0cf7
Some checks failed
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
- **SQLDelight:** Füge neue Queries (`countVereine`, `maxUpdated...`) zur SQLite-Datenbank hinzu und aktualisiere `DesktopMasterdataRepository`. - **ZNS-Sync:** Passe `ZnsImportState` an, um Pferde- und Funktionärsdaten zu unterstützen. - **Cloud-Sync:** Entferne redundante Auth-Header und setze Limits für Massensynchronisation auf 50.000 Datensätze. - **Masterdata-Service:** Stabilisiere Consul Health-Checks und implementiere Limit-Beschränkungen auf Controller-Ebene. |
||
|---|---|---|
| .. | ||
| docs | ||
| masterdata-api | ||
| masterdata-common | ||
| masterdata-domain | ||
| masterdata-infrastructure | ||
| masterdata-service | ||
| Dockerfile | ||
| README.md | ||
🧹 Masterdata Service
Der Masterdata Service ist ein zentraler Bounded Context innerhalb der Meldestelle-Biest Architektur. Er dient als " Single Source of Truth" für alle statischen und semi-statischen Stammdaten, die für den Turnierbetrieb und die Verwaltung von Reitern, Pferden und Organisationen (Vereinen) notwendig sind.
🎯 Zweck & Aufgaben
Dieser Service stellt sicher, dass alle anderen Contexts (wie registration-context oder actor-context) auf
konsistente und standardisierte Referenzdaten zugreifen können.
Hauptaufgaben:
- Geografische Daten: Verwaltung von Ländern (ISO-Codes), Bundesländern und deren OEPS-spezifischen Kürzeln.
- Sportliche Reglements: Bereitstellung von Altersklassen (ÖTO-konform), Sparten und Lizenzstufen.
- Infrastruktur: Verwaltung von Austragungsplätzen (Dimensionen, Bodenbeschaffenheit) innerhalb von Turnierstätten.
- Referenzdaten: Zentrale Pflege von Enums und Konstanten (z.B. Turniertypen, Status-Codes).
🏗️ Architektur & Modulstruktur
Der Service folgt einer Hexagonalen Architektur und ist als Gradle Multi-Modul-Projekt innerhalb des Backends organisiert. Dies ermöglicht eine saubere Trennung zwischen Fachlogik und technischer Infrastruktur.
| Modul | Beschreibung |
|---|---|
masterdata-domain |
KMP-Modul. Enthält die Domänenmodelle (LandDefinition, Altersklasse, etc.) und Repository-Interfaces. Keine Abhängigkeiten nach außen. |
masterdata-common |
Beinhaltet die fachliche Logik in Form von Use-Cases (Interaktoren). |
masterdata-api |
Stellt die REST-Schnittstellen mittels Ktor bereit. Enthält Controller, DTO-Mapping und das Idempotency-Plugin. |
masterdata-infrastructure |
Implementiert die Persistenzschicht mit Exposed (PostgreSQL) und bindet externe Dienste an. |
masterdata-service |
Der Spring Boot Host, der alle Module zusammenführt, die Konfiguration verwaltet und den Service startet. |
🛠️ Wichtige Domänenmodelle (Auszug)
LandDefinition: ISO-3166 konforme Länderdaten inklusive EU/EWR-Status und Wappen-URLs.Bundesland: Zuordnung zu Ländern, inklusive der für die OEPS-Satznummern relevanten Landes-Codes.Altersklasse: Definitionen basierend auf dem Geburtsjahr, Geschlecht und der Sparte (ÖTO § 39).Platz: Beschreibung von Austragungs- und Vorbereitungsplätzen für Turniere.
🔌 Schnittstellen (API)
Die APIs sind unter /api/v1/masterdata/... erreichbar.
Wichtige Endpunkte:
GET /countries: Liste aller unterstützten Länder.GET /bundeslaender: Regionale Gliederung (vorrangig Österreich).GET /altersklassen: Abfrage der gültigen Klassen für einen Reiter in einer bestimmten Sparte.GET /plaetze: Infrastruktur-Abfrage für Turnierplanung.
🧪 Entwicklung & Tests
- Unit-Tests: Befinden sich in den jeweiligen Modulen (v.a.
domainundcommon). - Integration-Tests: Nutzen Testcontainers für die Datenbankvalidierung (in
infrastructureundservice). - Idempotenz: Der Service nutzt ein spezialisiertes
IdempotencyPluginin der API-Schicht, um doppelte Schreiboperationen bei Netzwerkfehlern zu verhindern.
📜 ÖTO-Konformität
Sämtliche Stammdaten (insbesondere Altersklassen und Sparten) sind strikt nach dem ÖTO (Österreichische Turnierordnung) Regelwerk modelliert. Detaillierte Aufstellungen der verwendeten Definitionen finden sich hier:
- Strategische Roadmap (Phasen, Meilensteine, Verantwortlichkeiten)
- ÖTO-Stammdaten Dokumentation (Fachliche Logik)
- Turnier-Sparten & Klassen (Detaillierte Übersicht Springen/Dressur & C-NEU)
- Reiter-Lizenzen & Startberechtigungen (Lizenzstufen & Sportliche Relevanz)
- Richter & Parcoursbauer Qualifikationen (Befugnisse & Einsatzvorgaben)
- Gebührenordnung ÖTO 2026 (Nenn-/Startgelder & Geldpreise)
- Pferdeprüfungen (Jungpferde) (Dressur-/Springpferdeprotokolle)
- Pferdeprüfungen (Bewertungssystem) (Abzugslogik & qualitative Noten)
- Reiter-Prüfungen (Dressur & Stilspringen) (Fokus auf Sitz & Einwirkung)
- ZNS-Schnittstellen Spezifikation (Technisches Transfer-Format)
Änderungen am Regelwerk müssen hier zentral eingepflegt werden, damit sie systemweit (z.B. in der Nennungsprüfung) wirksam werden.
🧹 Curator-Hinweis: Diese Dokumentation wird laufend aktualisiert. Änderungen an der Domänenstruktur müssen in der
MASTER_ROADMAPreflektiert werden.