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

@@ -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).*