Stefan Mogeritsch
e8757c5c32
- Added `REITER_PRUEFUNGEN.md` and `PFERDEPRUEFUNGEN_BEWERTUNG.md` to document evaluation criteria, scoring logic, and system requirements for dressage and show jumping. - Updated `README.md` with links to new documentation on rider- and horse-specific regulations. - Created database schemas for `TurnierklasseTable`, `RichtverfahrenTable`, `GebuehrTable`, `LicenseTable`, and `RegulationConfigTable`, aligning with ÖTO 2026. - Logged architectural decisions and analysis in `session-logs` and created ADRs `0017-masterdata-importer-worker` and `0019-api-ingestion-layers`. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
54 lines
2.4 KiB
Markdown
54 lines
2.4 KiB
Markdown
---
|
|
type: ADR
|
|
status: AKZEPTIERT
|
|
owner: Lead Architect
|
|
date: 2026-03-30
|
|
---
|
|
|
|
# ADR-0018: Rule-Versionierung und -Management (ÖTO-Regeln)
|
|
|
|
## Status
|
|
|
|
Akzeptiert
|
|
|
|
## Kontext
|
|
|
|
Die ÖTO-Regeln (Österreichische Turnierordnung) für Dressur, Springen und andere Sparten ändern sich regelmäßig (
|
|
jährlich oder bei Bedarf). Das System muss in der Lage sein, Stammdaten (Altersklassen, Lizenzen, Richtverfahren,
|
|
Gebühren) für ein Turnier basierend auf dem zum Turnierzeitpunkt gültigen Regelwerk zu validieren und anzuzeigen. Eine
|
|
rein Code-basierte Regelverwaltung (Hardcoding) ist aufgrund der Dynamik und Offline-Fähigkeit nicht praktikabel.
|
|
|
|
## Entscheidung
|
|
|
|
ÖTO-Regeln werden als **versionierte Datensätze in der Datenbank** verwaltet (Regulation-as-Data).
|
|
|
|
Details:
|
|
|
|
1. **Versionierungs-Schema**: Alle Regel-Datensätze (z.B. Lizenz-Klasse-Matrix, Altersklassen-Berechnung) erhalten
|
|
`valid_from` und `valid_to` Zeitstempel.
|
|
2. **Aktives Regel-Set**: Die Applikationslogik ermittelt zur Laufzeit (z.B. basierend auf dem Turnierdatum) das jeweils
|
|
aktive Regel-Set aus der Datenbank.
|
|
3. **Seed-Strategie**: Zu Beginn jeder Saison (oder bei Major-Updates) wird ein neues Regel-Set als Seed in die
|
|
Datenbank eingespielt. Das "Regel-Set 2026" dient als Basis.
|
|
4. **Unveränderlichkeit (Immutability)**: Bestehende, in Turnieren verwendete Regeln dürfen nicht überschrieben werden.
|
|
Bei Änderungen wird ein neuer Datensatz mit neuem Gültigkeitsbereich angelegt (SCD Type 2 Pattern).
|
|
|
|
## Konsequenzen
|
|
|
|
- **Positiv**: Hohe Flexibilität ohne Code-Deployments (Config-over-Code).
|
|
- **Positiv**: Historische Turniere bleiben nachvollziehbar, da sie auf das damals gültige Regelwerk verweisen.
|
|
- **Negativ**: Erhöhte Komplexität bei Datenbank-Abfragen (immer Zeitbezug erforderlich).
|
|
- **Negativ**: Notwendigkeit für robuste Administrations-Schnittstellen oder SQL-Seeds zur Regelpflege.
|
|
|
|
## Betrachtete Alternativen
|
|
|
|
- **Hardcoding in Kotlin-Use-Cases**: Schneller zu implementieren, aber unflexibel bei unterjährigen Regeländerungen und
|
|
historischer Auswertung schwierig.
|
|
- **Git-basierte Konfiguration (YAML/JSON)**: Gut für CI/CD, aber schwierig für Offline-Szenarien ohne vollen
|
|
Repository-Sync; Datenbank-Integration für Abfragen komplexer.
|
|
|
|
## Referenzen
|
|
|
|
- [ROADMAP.md](../ROADMAP.md)
|
|
- [Abteilungs-Trennungs-Schwellenwerte.md](../../../docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md)
|