meldestelle/backend/services/masterdata
StefanMoCoAt 7e3a5aa49e
Some checks are pending
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Waiting to run
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Waiting to run
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Waiting to run
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Waiting to run
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Waiting to run
Set static health-check-port to 8086 in application.yml for consistent configuration.
2026-04-13 23:30:45 +02:00
..
docs Refactor license matrix and tokenizer logic: rename LicenseTable to LizenzTable, replace LicenseMatrixService with LizenzMatrixService, enhance tokenizer with normalized and fallback token handling, improve ZNS import for license extraction, and update related documentation. 2026-04-06 23:52:06 +02:00
masterdata-api Remove domain models and services related to Abteilung, AbteilungsRegelService, and Bewerb: cleanup unnecessary entities, validation logic, and tests across backend modules. 2026-04-13 21:58:25 +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 Remove domain models and services related to Abteilung, AbteilungsRegelService, and Bewerb: cleanup unnecessary entities, validation logic, and tests across backend modules. 2026-04-13 21:58:25 +02:00
masterdata-infrastructure Refactor license matrix and tokenizer logic: rename LicenseTable to LizenzTable, replace LicenseMatrixService with LizenzMatrixService, enhance tokenizer with normalized and fallback token handling, improve ZNS import for license extraction, and update related documentation. 2026-04-06 23:52:06 +02:00
masterdata-service Set static health-check-port to 8086 in application.yml for consistent configuration. 2026-04-13 23:30:45 +02:00
Dockerfile Remove outdated BillingController implementation, resolve conflicting bean definitions across modules, and retain the updated BillingController for consistency with frontend API logic. 2026-04-12 21:51:52 +02:00
README.md feat(docs): expand masterdata documentation with Reiter- and Pferdeprüfungen 2026-03-30 14:29:58 +02:00

🧹 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:

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