feat(docs): refine bounded-context definitions and improve glossary clarity
- Renamed `actor-context` to `master-data-context`, emphasizing its role as the central library for core entities and ÖTO rulebook. - Enhanced `competition-context` with a focus on the atomic nature of `Abteilung` for results and start lists. - Updated glossary with standardized terms (`Stammdaten`, `Abteilung`, `Sparte`) and deprecated ambiguous ones (e.g., `Akteur`). - Strengthened documentation with ÖTO-conformant invariants and clarified responsibilities across bounded contexts. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -37,7 +37,7 @@ Schnittstellen.
|
||||
| Context | Verantwortlichkeit | Priorität | Phase |
|
||||
|----------------------------|------------------------------------------------------|-----------|---------|
|
||||
| `registration-context` | Nennungs-Workflow (Herzstück des Systems) | **P1** | Phase 4 |
|
||||
| `actor-context` | Reiter, Pferde, Funktionäre, Vereine, ZNS-Stammdaten | **P1** | Phase 4 |
|
||||
| `master-data-context` | Reiter, Pferde, Vereine, ZNS-Daten, ÖTO-Regelwerk | **P1** | Phase 4 |
|
||||
| `competition-context` | Bewerbe, Startlisten, Ergebnisse, Abteilungs-Logik | **P2** | Phase 5 |
|
||||
| `event-management-context` | Veranstaltung, Turnier, Ausschreibung, Genehmigungen | **P2** | Phase 5 |
|
||||
| `billing-context` | Abrechnung, Kassa, Gebühren, Konten | **P3** | Phase 6 |
|
||||
@@ -73,49 +73,56 @@ Schnittstellen.
|
||||
|
||||
---
|
||||
|
||||
#### `actor-context` — Unterstützende Domäne (Supporting Domain)
|
||||
#### `master-data-context` — Unterstützende Domäne (Supporting Domain)
|
||||
|
||||
**Verantwortlichkeit:** Stammdaten aller Akteure und Synchronisation mit dem ZNS (Zentrales Nennungs-System).
|
||||
**Verantwortlichkeit:** Stammdaten aller Akteure, Synchronisation mit dem ZNS (Zentrales Nennungs-System) sowie die "
|
||||
Library of Truth" für das ÖTO/FEI Regelwerk.
|
||||
|
||||
**Aggregate Roots:**
|
||||
|
||||
- `DomReiter` – Reiter mit Lizenz, Satznummer, Startkarte
|
||||
- `DomPferd` – Pferd mit Lebensnummer, Kopfnummer, Satznummer
|
||||
- `DomFunktionär` – Person mit Turnier-Rolle und Qualifikation
|
||||
- `DomFunktionär` – Person mit Turnier-Rolle und Qualifikation (Richter, Parcoursbauer)
|
||||
- `DomVerein` – OEPS-Mitgliedsverein (Veranstalter)
|
||||
- `DomRegelwerk` – Richtverfahren (§ 204 Springen, § 104 Dressur etc.), Sparten, Klassen
|
||||
- `DomGebührenSatz` – Standard-Sätze für Sportförderbeiträge und Tierwohl-Euros
|
||||
|
||||
**Ubiquitous Language (Auswahl):**
|
||||
|
||||
- `Satznummer`, `Lebensnummer`, `Kopfnummer`, `FEI-ID`, `Lizenz`, `Startkarte`, `Sperrliste`, `Gastreiter`
|
||||
- `Satznummer`, `Lebensnummer`, `Kopfnummer`, `FEI-ID`, `Lizenz`, `Startkarte`, `Gastreiter`, `Richtverfahren`,
|
||||
`Paragraph`, `Sparte`, `Klasse`
|
||||
|
||||
**Kern-Invarianten:**
|
||||
|
||||
- `Satznummer` ist der primäre Schlüssel für den ZNS-Datenaustausch
|
||||
- `Lebensnummer` und `Kopfnummer` sind **nicht** als Datenbankschlüssel geeignet (ZNS-Inkonsistenzen)
|
||||
- ZNS-Daten werden lokal gecacht (Offline-First); Synchronisation im Hintergrund
|
||||
- ZNS-Daten sind schreibgeschützt; Erweiterungen erfolgen über Verknüpfungen im `identity-context`
|
||||
- Das Regelwerk dient als Basis für alle fachlichen Validierungen im System
|
||||
- ZNS-Daten werden lokal gecacht (Offline-First)
|
||||
|
||||
---
|
||||
|
||||
#### `competition-context` — Unterstützende Domäne (Supporting Domain)
|
||||
|
||||
**Verantwortlichkeit:** Strukturierung von Bewerben, Erstellung von Startlisten, Erfassung von Ergebnissen.
|
||||
**Verantwortlichkeit:** Strukturierung von Bewerben, Erstellung von Startlisten, Erfassung von Ergebnissen. Die *
|
||||
*Abteilung** ist hierbei die kleinste operative Einheit.
|
||||
|
||||
**Aggregate Roots:**
|
||||
|
||||
- `DomBewerb` – Einzelne sportliche Prüfung mit Bewerbsnummer, Sparte, Klasse, Richtverfahren
|
||||
- `DomAbteilung` – Untereinheit eines Bewerbs mit eigenem Teilnehmerkreis und Platzierung
|
||||
- `DomStartliste` – Geordnete Liste der Starter einer Abteilung
|
||||
- `DomErgebnis` – Ergebnis eines Starts (Platzierung, Punkte, Zeit)
|
||||
- `DomAbteilung` – Atomare Einheit für Startlisten und Ergebnisse (ÖTO § 39). Ein Bewerb ist der organisatorische
|
||||
Container.
|
||||
- `DomBewerb` – Klammer um eine oder mehrere Abteilungen mit gemeinsamer Bewerbsnummer, Sparte, Klasse.
|
||||
- `DomStartliste` – Geordnete Liste der Starter einer Abteilung.
|
||||
- `DomErgebnis` – Ergebnis eines Starts (Platzierung, Punkte, Zeit) innerhalb einer Abteilung.
|
||||
|
||||
**Ubiquitous Language (Auswahl):**
|
||||
|
||||
- `Bewerb`, `Prüfung`, `Abteilung`, `Abteilungsnummer`, `Startliste`, `Richtverfahren`, `Klasse/Höhe`
|
||||
- `Abteilung`, `Abteilungsnummer`, `Bewerb`, `Prüfung`, `Startliste`, `Richtverfahren`, `Klasse/Höhe`
|
||||
|
||||
**Kern-Invarianten:**
|
||||
|
||||
- Startlisten und Ergebnislisten werden auf **Abteilungsebene** verwaltet
|
||||
- Abteilungs-Schwellenwerte gemäß ÖTO § 39 lösen **Warnungen** aus (→ `Override-Event`)
|
||||
- Vollständige Schwellenwert-Tabellen:
|
||||
`docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`
|
||||
- Ein Bewerb kann mehrere Abteilungen haben (z.B. Trennung nach R1/R2 Lizenzen)
|
||||
|
||||
---
|
||||
|
||||
@@ -164,20 +171,23 @@ Schnittstellen.
|
||||
|
||||
#### `identity-context` — Generische Domäne (Generic Domain)
|
||||
|
||||
**Verantwortlichkeit:** Authentifizierung, Rollen-Management, Berechtigungsprüfung (via Keycloak).
|
||||
**Verantwortlichkeit:** Authentifizierung, Rollen-Management, Berechtigungsprüfung (via Keycloak) sowie die Verwaltung
|
||||
von erweiterten Profilen.
|
||||
|
||||
**Aggregate Roots:**
|
||||
|
||||
- `DomBenutzer` – Systembenutzer mit Rollen (TBA, Veranstalter, Meldestelle, Richter)
|
||||
- `DomProfil` – Erweiterte Daten (Logo, Bio, Kontakt) verknüpft mit einer `Satznummer` aus dem `master-data-context`
|
||||
- `DomRolle` – Definierte Rolle mit Berechtigungen
|
||||
|
||||
**Ubiquitous Language (Auswahl):**
|
||||
|
||||
- `TBA`, `Veranstalter`, `Meldestelle`, `Richter`, `Rolle`, `Berechtigung`
|
||||
- `TBA`, `Veranstalter`, `Meldestelle`, `Richter`, `Profil-Link`, `Rolle`, `Berechtigung`
|
||||
|
||||
**Kern-Invarianten:**
|
||||
|
||||
- Keycloak ist der einzige Identity Provider (→ ADR-0006)
|
||||
- Ein System-Benutzer kann über eine Link-Tabelle mit amtlichen ZNS-Daten verknüpft werden
|
||||
- Rollen sind turnierbezogen (ein Benutzer kann bei Turnier A TBA und bei Turnier B Richter sein)
|
||||
|
||||
---
|
||||
@@ -186,8 +196,12 @@ Schnittstellen.
|
||||
|
||||
### Positive
|
||||
|
||||
- **Fachliche Klarheit:** Jeder Context hat eine klar definierte Verantwortlichkeit und eigene Ubiquitous Language
|
||||
- **Unabhängige Entwicklung:** P1-Contexts (`registration-context`, `actor-context`) können ohne P2/P3 entwickelt werden
|
||||
- **Fachliche Klarheit:** Jeder Context hat eine klar definierte Verantwortlichkeit und eigene Ubiquitous Language. Die
|
||||
Umbenennung in `master-data-context` schärft das Verständnis als zentrale Library of Truth.
|
||||
- **Abteilungs-Fokus:** Die Anerkennung der Abteilung als kleinste Einheit im `competition-context` löst Inkonsistenzen
|
||||
bei Start- und Ergebnislisten.
|
||||
- **Unabhängige Entwicklung:** P1-Contexts (`registration-context`, `master-data-context`) können ohne P2/P3 entwickelt
|
||||
werden
|
||||
- **Offline-First:** Jeder Context kann seinen eigenen lokalen Cache verwalten (SQLDelight)
|
||||
- **ÖTO-Konformität:** Die Context-Grenzen spiegeln die Struktur des ÖTO-Regelwerks wider
|
||||
- **Erweiterbarkeit:** `series-context` kann in Phase 2+ ohne Änderungen an bestehenden Contexts hinzugefügt werden
|
||||
|
||||
Reference in New Issue
Block a user