History

StefanMoCoAt 9223305613 Adjust `V011` migration: clarify redundant field removal in `V010`, ensure `reiter_id` addition and foreign key constraint establishment. Update changelog accordingly.		2026-04-06 14:23:09 +02:00
..
docs	docs(rulebook): update TURNIER_KLASSEN documentation for ÖTO 2026 compliance	2026-04-02 13:58:00 +02:00
masterdata-api	Integrate qualification master data (`QualifikationMasterTable`) with functionary models, update schema and repository logic, refactor `satzID` references, and harmonize database migration (`V010`).	2026-04-06 13:59:14 +02:00
masterdata-common	feat(masterdata): introduce Regulation domain with API, persistence, and metrics integration	2026-03-30 15:38:18 +02:00
masterdata-domain	Link `Funktionaer` to `Reiter` via `reiter_id`, implement `findByName` in `ReiterRepository`, optimize ZNS import for functionary-reiter matching, remove redundant fields from `FunktionaerTable`, and add database migration `V011`.	2026-04-06 14:21:11 +02:00
masterdata-infrastructure	Link `Funktionaer` to `Reiter` via `reiter_id`, implement `findByName` in `ReiterRepository`, optimize ZNS import for functionary-reiter matching, remove redundant fields from `FunktionaerTable`, and add database migration `V011`.	2026-04-06 14:21:11 +02:00
masterdata-service	Adjust `V011` migration: clarify redundant field removal in `V010`, ensure `reiter_id` addition and foreign key constraint establishment. Update changelog accordingly.	2026-04-06 14:23:09 +02:00
Dockerfile	chore(ci): Align GH Workflows with Docker SSoT, new paths; minimal SSoT guard; staticAnalysis (#23 )	2025-12-03 12:03:40 +01:00
README.md	feat(docs): expand masterdata documentation with Reiter- and Pferdeprüfungen	2026-03-30 14:29:58 +02:00

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. domain und common).
Integration-Tests: Nutzen Testcontainers für die Datenbankvalidierung (in infrastructure und service).
Idempotenz: Der Service nutzt ein spezialisiertes IdempotencyPlugin in 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_ROADMAP reflektiert werden.