docs: add domain workshop results and event structure diagram
- Documented outcomes of the 2026-03-17 domain workshop under `docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md`. - Added a structural diagram visualizing events, tournaments, and competitions with their relationships under `docs/03_Domain/01_Core_Model/Entities/Event_Structure_Diagram.md`. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
parent
119af6fd6b
commit
b6f4f43122
|
|
@ -0,0 +1,89 @@
|
|||
# Turnier- & Bewerbsstruktur Diagramm
|
||||
|
||||
Dieses Diagramm zeigt die strukturelle Hierarchie und die Beziehungen zwischen Event, Turnier und Bewerb basierend auf
|
||||
dem ÖTO-Regelwerk und den Anforderungen der OEPS-Schnittstelle.
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
%% Entities
|
||||
EVENT {
|
||||
string id PK "UUID"
|
||||
string name "z.B. Apropos Pferd 2026"
|
||||
date start_date
|
||||
date end_date
|
||||
string location
|
||||
string organizer_id FK "Veranstalter (Akteur)"
|
||||
string status "PLANNING, ACTIVE, ARCHIVED"
|
||||
}
|
||||
|
||||
TOURNAMENT {
|
||||
string id PK "UUID"
|
||||
string event_id FK
|
||||
string oeps_number "z.B. 21001 (A-Satz)"
|
||||
string category "z.B. CSN-A, CDN-B"
|
||||
string ruleset "OETO oder FEI"
|
||||
}
|
||||
|
||||
COMPETITION {
|
||||
string id PK "UUID"
|
||||
string tournament_id FK
|
||||
string code_internal "2-stellig (B-Satz Pos. 2)"
|
||||
string code_official "3-stellig (B-Satz Pos. 61)"
|
||||
int division_id "Abteilung (0=keine, 1=Abt. 1...)"
|
||||
string title "z.B. Standardspringprüfung"
|
||||
string category "Klasse z.B. L, M, S*"
|
||||
string discipline "S (Springen), D (Dressur), C"
|
||||
string scoring_method "Richtverfahren (z.B. A0, A2)"
|
||||
int start_fee "in Cent"
|
||||
string status "OPEN, RUNNING, FINISHED"
|
||||
}
|
||||
|
||||
OFFICIALS {
|
||||
string id PK "UUID"
|
||||
string tournament_id FK "oder competition_id"
|
||||
string actor_id FK "Richter / Parcoursbauer"
|
||||
string role "Hauptrichter, Richter, TD"
|
||||
}
|
||||
|
||||
%% Relationships
|
||||
EVENT ||--o{ TOURNAMENT: "beinhaltet"
|
||||
TOURNAMENT ||--o{ COMPETITION: "besteht aus (B-Satz)"
|
||||
TOURNAMENT ||--o{ OFFICIALS: "hat Funktionäre (C-Satz)"
|
||||
COMPETITION ||--o{ OFFICIALS: "wird gerichtet von"
|
||||
```
|
||||
|
||||
## Erläuterung zum Modell (Option B)
|
||||
|
||||
### 1. `EVENT` (Veranstaltung)
|
||||
|
||||
Das **Event** ist der übergeordnete organisatorische Rahmen (z.B. "Pferdefestival 2026"). Es hat ein Datum, einen Ort
|
||||
und einen Veranstalter. Es existiert unabhängig von den strikten OEPS-Regularien und ist primär für die administrative
|
||||
Verwaltung (Rechnungsstellung, Anlagenplanung) wichtig.
|
||||
|
||||
### 2. `TOURNAMENT` (Turnier)
|
||||
|
||||
Ein Event kann mehrere **Turniere** beinhalten (z.B. ein nationales CSN-B und gleichzeitig ein internationales CSI2*).
|
||||
Das Turnier ist die Instanz, die strikt an das Regelwerk gebunden ist:
|
||||
|
||||
* Es korrespondiert 1:1 mit dem **A-Satz** des OEPS-Pflichtenhefts.
|
||||
* Es hat eine eindeutige 5-stellige `oeps_number`.
|
||||
* Es legt fest, nach welchem Regelwerk (ÖTO vs. FEI) geritten und ausgewertet wird.
|
||||
|
||||
### 3. `COMPETITION` (Bewerb / Prüfung)
|
||||
|
||||
Die kleinste sportliche Einheit und das Herzstück der Ausschreibung.
|
||||
Hier finden wir die direkte Verbindung zum **B-Satz** der Legacy-Spezifikation:
|
||||
|
||||
* **Abteilungen (`division_id`):** Laut OEPS-Schnittstelle wird jede Abteilung (z.B. R1-Reiter getrennt von R2-Reitern)
|
||||
datentechnisch fast wie ein eigener Bewerb behandelt. In unserer Datenbank repräsentieren wir jede Abteilung als
|
||||
eigene Zeile in der Tabelle `competition` (oder verknüpfen sie intelligent), da jede Abteilung ihre eigene
|
||||
Ergebnisliste und ihr eigenes Preisgeld hat.
|
||||
* **Nummerierung:** Intern 2-stellig (`code_internal`), für Turniere ab 100 Bewerben offiziell 3-stellig (
|
||||
`code_official` an Stelle 61).
|
||||
* **Richtverfahren:** Entscheidet darüber, wie Fehler und Zeit (Springen) oder Wertnoten (Dressur) in ein Ranking
|
||||
übersetzt werden.
|
||||
|
||||
### 4. `OFFICIALS` (Funktionäre)
|
||||
|
||||
Dies entspricht dem **C-Satz**. Richter und Parcoursbauer müssen einem Turnier oder spezifisch einem Bewerb zugewiesen
|
||||
werden. Deren 6-stellige OEPS-Nummer (Satznummer) wird für den Ergebnis-Export benötigt.
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
type: Reference
|
||||
status: ACTIVE
|
||||
owner: Lead Architect
|
||||
date: 2026-03-17
|
||||
---
|
||||
|
||||
# Ergebnisse: Domain Workshop vom 17.03.2026
|
||||
|
||||
**Teilnehmer:** Owner (Fachexperte), 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer],
|
||||
🎨 [Frontend Expert], 🖌️ [UI/UX Designer]
|
||||
|
||||
## 🎯 Fokus des Workshops
|
||||
|
||||
* Klärung der Kompetenzen vor Ort (Turnierbeauftragter vs. Regelwerk).
|
||||
* Analyse der Kassenführung und komplexer Gebühren-Szenarien.
|
||||
* Management von Funktionären und deren Qualifikationen.
|
||||
* Erster Entwurf für den Workflow der Turnieranlage (UI/UX).
|
||||
|
||||
---
|
||||
|
||||
## 💡 Erkenntnisse der Agents
|
||||
|
||||
### 📜 [ÖTO/FEI Rulebook Expert]
|
||||
|
||||
1. **Autorität des Turnierbeauftragten (TBA):** Die Analyse der ÖTO (§ 24, § 25) bestätigt die Praxis-Erfahrung: Der TBA
|
||||
ist die höchste Instanz vor Ort und kann in Absprache mit dem Veranstalter von der Ausschreibung abweichende, für
|
||||
alle verbindliche Entscheidungen treffen. **Das System muss daher bei Regelkonflikten immer einen manuellen "
|
||||
Override" durch die Meldestelle ermöglichen.**
|
||||
2. **Gebührenlogik & Abrechnung:** Das "Hansi"-Szenario (Klassenüberschreitung, Reiterwechsel, Nachnennung) hat die
|
||||
enorme Komplexität der Gebührenstruktur verdeutlicht. Es muss zwingend unterschieden werden zwischen:
|
||||
* **Nenngeld:** Grundgebühr, oft im Voraus via ZNS bezahlt.
|
||||
* **Startgeld:** Gebühr pro einzelnem Bewerb.
|
||||
* **Nachnenngebühren:** Strafaufschlag bei später Meldung.
|
||||
* **Nebengebühren:** Sportförderbeitrag, Tierwohl-Euro (pro Start).
|
||||
Die Möglichkeit für den Veranstalter, auf Gebührenanteile (z.B. Nachnenngebühr) zu verzichten, muss zwingend
|
||||
abgebildet werden.
|
||||
3. **Qualifikation von Funktionären:** Die Qualifikationen für Richter und Parcoursbauer sind in der Datei
|
||||
`RICHT01.DAT` (ZNS-Daten) enthalten. Diese müssen beim Import ausgelesen und im System gegen die Anforderungen des
|
||||
jeweiligen Bewerbs (Klasse, Sparte) validiert werden.
|
||||
|
||||
### 👷 [Backend Developer]
|
||||
|
||||
1. **Neuer Bounded Context "Billing & Accounting":** Die Kassenführung ist zu komplex und eigenständig, um sie mit dem
|
||||
sportlichen Kern (Nennung/Ergebnis) zu vermischen. Wir etablieren einen separaten Bounded Context mit dediziertem
|
||||
Datenmodell für **Konten (pro "Zahler"), Transaktionen und Gebühren**.
|
||||
2. **Architektur "Nennungstausch":** Der Tausch einer Nennung (Reiter oder Pferd) wird *nicht* als einfaches Löschen und
|
||||
Neuanlegen implementiert. Es wird als **Transfer-Operation** abgebildet. Bereits bezahlte Nenngelder verbleiben als
|
||||
Guthaben auf dem Konto des ursprünglichen Zahlers (oder sind an das Pferd gebunden) und können auf die neue Nennung
|
||||
angerechnet werden. Nur Differenzen und Tauschgebühren werden neu verbucht.
|
||||
3. **Validierungs-Service für Funktionäre:** Es wird ein Service implementiert, das bei der Zuweisung eines
|
||||
Richters/Parcoursbauers zu einem Bewerb dessen Qualifikationen (aus den ZNS-Daten) prüft. Wichtig: Die API liefert
|
||||
bei Mismatches nur eine `WARNUNG`, keinen blockierenden `FEHLER`, um den "Override" durch die Meldestelle (siehe
|
||||
Rulebook Expert) zu garantieren.
|
||||
|
||||
### 🎨 [Frontend Expert] & 🖌️ [UI/UX Designer]
|
||||
|
||||
1. **Workflow-Übernahme (Don't reinvent the wheel):** Die vom Owner bereitgestellten Screenshots des Altsystems (
|
||||
`Turnier-Transfer.PNG`, `Turnier-Richter.PNG` etc.) definieren einen praxiserprobten Workflow. Dieser wird als
|
||||
Blaupause für das neue UI verwendet.
|
||||
2. **Modernes UI-Konzept (Wizard-Ansatz):** Anstelle vieler separater Fenster (wie im Altsystem) wird die Turnieranlage
|
||||
in einem **geführten, schrittweisen Prozess** (Wizard oder übersichtliche Tab-Struktur) abgebildet.
|
||||
* *Schritt 1:* Stammdaten & ZNS-Import
|
||||
* *Schritt 2:* Konfiguration (Austragungsplätze, Preisliste)
|
||||
* *Schritt 3:* Team (Zuweisung von Richtern, Parcoursbauern)
|
||||
* *Schritt 4:* Bewerbsanlage
|
||||
3. **Smart UI:** Die Oberfläche wird den vertrauten Workflow bieten, aber durch **Echtzeit-Validierung** (z.B. visuelle
|
||||
Warnung bei Zuweisung eines Richters ohne passende Lizenz) und **intelligente Suchfelder** (Auto-Complete) die
|
||||
Dateneingabe erheblich beschleunigen und absichern.
|
||||
|
||||
---
|
||||
*Nächste Schritte: Detaillierung des ZNS-Imports (Stammdaten & Akteure).*
|
||||
Loading…
Reference in New Issue
Block a user