# Ergebnisse Domain Workshop (17.03.2026)

**Teilnehmer:** Owner, 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer], 🎨 [Frontend Expert],
🖌️ [UI/UX Designer]

## 📜 [ÖTO/FEI Rulebook Expert] - Erkenntnisse

1. **Autorität des Turnierbeauftragten (TBA):**
   Die Analyse der ÖTO (§ 24, § 25) bestätigt die Aussage des Owners: 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):**
   Die Komplexität der Gebührenstruktur wurde stark verdeutlicht. Es muss klar unterschieden werden zwischen:
  * **Nenngeld** (Grundgebühr, oft im Voraus via ZNS bezahlt)
  * **Startgeld** (pro Bewerb)
  * **Nachnenngebühren** (Aufschlag bei später Nennung, oft verhandelbar)
  * **Nebengebühren** (Sportförderbeitrag, Tierwohl-Euro - pro Start fällig)
    Die Möglichkeit für den Veranstalter, auf Gebührenanteile (z.B. Nachnenngebühr) zu verzichten, muss im
    Abrechnungssystem einfach abbildbar sein.

3. **Qualifikation von Funktionären:**
   Die Qualifikationen für Richter und Parcoursbauer sind in der Datei `RICHT01.DAT` der ZNS-Daten enthalten. Diese
   Qualifikationen müssen gegen die Anforderungen des jeweiligen Bewerbs (Klasse, Sparte) validiert werden.

## 👷 [Backend Developer] - Erkenntnisse

1. **Bounded Context "Billing & Accounting":**
   Die Kassenführung ist zu komplex und hat zu viele eigene Regeln, um sie eng mit dem sportlichen Kern (
   Nennung/Ergebnis) zu koppeln. Wir werden dies als separaten Bounded Context mit eigenen Services und einem
   dedizierten Datenmodell für Konten, Transaktionen und Gebühren umsetzen. Die Abrechnung muss kontobasiert pro Zahler
   erfolgen (nicht nur pro Reiter).

2. **Implementierung "Nennungstausch":**
   Der Tausch einer Nennung (Reiter/Pferd) wird nicht als reines Storno + Neu-Buchung implementiert, sondern als *
   *Transfer-Operation**. Bereits bezahlte Nenngelder werden als Guthaben auf dem Konto des ursprünglichen Zahlers (oder
   des Pferdes) geführt und können auf die neue Nennung angerechnet werden. Das System berechnet und verbucht
   automatisch die anfallenden Differenzen und Tauschgebühren.

3. **Validierungs-Service für Funktionäre:**
   Es wird eine Backend-Funktion implementiert, die bei der Zuweisung eines Richters/Parcoursbauers zu einem Bewerb
   dessen Qualifikationen (aus den importierten ZNS-Daten) gegen die Anforderungen des Bewerbs prüft. Die API wird bei
   einem Mismatch eine `WARNUNG` zurückgeben, aber keinen harten `FEHLER`, um den vom Rulebook Expert bestätigten "
   Override" durch die Meldestelle zu ermöglichen.

4. **ZNS-Import, Fremddaten (Zuchtverbände) & Event Sourcing:**
   Die unsauberen und oft wechselnden ZNS-Daten des OEPS werden nicht destruktiv in Datenbanktabellen überschrieben.
   Stattdessen wird eine **Event Sourcing** Architektur gewählt.
  * Das Hochladen der `zns.zip` triggert einen Parser, der Änderungen (Updates bei Lizenzen, neue Akteure) als
    zeitgestempelte Events (z.B. `ActorUpdatedEvent`) in einem "Event Log" ablegt.
  * Fremddaten (z.B. von Zuchtverbänden wie dem AWÖ) können über dedizierte Parser eingelesen und in dieselben
    Standard-Events übersetzt werden.
  * **Manuelle Korrekturen durch die Meldestelle** (wegen fehlerhafter OEPS-Daten) erzeugen "Override-Events", die
    Vorrang vor veralteten Import-Daten haben.
  * Für die schnelle Anzeige und Offline-Synchronisation werden aus diesen Events saubere Projektionen ("Read Models")
    und turnierspezifische Snapshots gebaut.

## 🎨 [Frontend Expert] & 🖌️ [UI/UX Designer] - Erkenntnisse

1. **Workflow-Übernahme als Grundlage:**
   Die vom Owner bereitgestellten Screenshots des Altsystems (`BilderSuDo/`) definieren einen praxiserprobten, schnellen
   und vom User extrem gut akzeptierten Workflow. Diese Screens dienen als absolute Blaupause für das neue UI/UX-Design.

2. **Der "Bewerbe anlegen"-Workflow (`Bewerbe.PNG` etc.):**
  * Zweigeteilte Ansicht (Master-Detail): Links Liste/Filter aller Bewerbe, Rechts Detail-Tabs.
  * Detail-Tabs gliedern sich in: *Bewertung* (Richtverfahren), *Geldpreis* (Dotierung nach Platzierung), *Ort/Zeit* (
    Ablaufplanung mit Zeit-pro-Starter-Logik).
  * *Design-Vorgabe:* Diese Informationsarchitektur wird in moderne Compose-Layouts (z.B. List-Detail-Pane) überführt,
    die Logik bleibt identisch.

3. **Die zentrale "Nennungs-Maske" (`Nennungen.PNG`):**
  * Dies ist das **Herzstück der Meldestelle** ("Das Telefon läutet...").
  * Extrem schnelle Suche via Kopfnummer oder Name (mit sofortiger Auto-Completion).
  * Anzeige der Meta-Daten (z.B. Besitzer) für sofortige Identifikation.
  * Direkte Zuweisung zu Bewerben via Klick aus einer Liste unten.
  * Berücksichtigung von Startwünschen ("vorne", "hinten").
  * *Design-Vorgabe:* Diese Maske muss auf **absolute Tastatur- & Schnellbedienbarkeit** optimiert werden (Hotkeys,
    Tab-Flow). Sie fungiert als Dashboard (Absprung zu Startliste, Kassa).
  * **Self-Service Äquivalenz:** Das Webformular für den Reiter nutzt im Hintergrund dieselbe Logik, um die Meldestelle
    maximal zu entlasten.

4. **Startlisten-Erstellung (`Startlisten.PNG`):**
  * Schneller Wechsel zwischen Bewerben über Nummern-Leiste oben (Tab-Ersatz).
  * Berücksichtigung der beim Nennen erfassten Wünsche ("vorne", "hinten").

5. **Ergebnis-Erfassung am Richterturm (`Ergebnisliste.PNG`):**
  * Schnelleingabe-Maske optimiert für den fließenden Ablauf.
  * Oben: Gesamtergebnis / Unten: Startliste als Warteschlange / Mitte: Aktueller Reiter in Eingabe.
  * Absoluter Fokus auf **"Enter & Tabulator"-Workflow**. Ein Mausklick darf für den Standard-Ablauf nicht nötig sein.
  * Spontane Abweichungen von der Startfolge (nächster Reiter kommt früher) müssen durch simplen Doppelklick auf die
    Warteschlange lösbar sein.
  * Entscheidung über Anzahl der Platzierten bleibt flexibel und ist durch die Meldestelle überschreibbar (ÖTO als
    Richtlinie, Veranstalter hat letztes Wort).

## 🏗️ [Lead Architect] - Strategischer Fokus (MVP Phase 1)

Um zügig einen echten Mehrwert zu generieren, wird der Scope für die erste Ausbaustufe (MVP) hart eingegrenzt:

* **Turnier-Kategorien:** Fokus auf **C-NEU** und **C**.
* **Sparten:** Fokus ausschließlich auf **Dressur (D)** und **Springen (S)**.
* *Begründung:* Diese Eingrenzung reduziert die initial benötigte Komplexität der Regelwerks-Implementierung enorm,
  deckt aber gleichzeitig das absolute "Brot-und-Butter"-Geschäft für kleine bis mittlere Veranstalter ab.
