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>

docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md

@@ -1,72 +1,102 @@
----
-type: Reference
-status: ACTIVE
-owner: Lead Architect
-date: 2026-03-17
----
+# Ergebnisse Domain Workshop (17.03.2026)
 
-# Ergebnisse: Domain Workshop vom 17.03.2026
+**Teilnehmer:** Owner, 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer], 🎨 [Frontend Expert],
+🖌️ [UI/UX Designer]
 
-**Teilnehmer:** Owner (Fachexperte), 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer],
-🎨 [Frontend Expert], 🖌️ [UI/UX Designer]
+## 📜 [ÖTO/FEI Rulebook Expert] - Erkenntnisse
 
-## 🎯 Fokus des Workshops
+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.
 
-* 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).
+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.
 
-## 💡 Erkenntnisse der Agents
+## 👷 [Backend Developer] - Erkenntnisse
 
-### 📜 [ÖTO/FEI Rulebook Expert]
+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).
 
-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.
+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.
 
-### 👷 [Backend Developer]
+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.
 
-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.
+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]
+## 🎨 [Frontend Expert] & 🖌️ [UI/UX Designer] - Erkenntnisse
 
-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.
+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.
 
----
-*Nächste Schritte: Detaillierung des ZNS-Imports (Stammdaten & Akteure).*
+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.