meldestelle/docs/99_Journal/2026-03-24_Session_Log_DDD_Ubiquitous_Language.md

date	type	agents	status
2026-03-24	Session Log	UI/UX Designer, Lead Architect, ÖTO/FEI Rulebook Expert, Curator	COMPLETED

Session Log – DDD-Analyse, Terminologie & Ubiquitous Language

🧹 [Curator] | 24. März 2026

---

Zusammenfassung der Session

Diese Session umfasste mehrere aufeinander aufbauende Diskussionen rund um das Domain-Design, die ÖTO-konforme Terminologie und die Erstellung der offiziellen Ubiquitous Language.

---

Durchgeführte Aktivitäten

1. Figma-Analyse (Vision_01 → Vision_02 → Vision_03)

• Alle drei Figma-Prototypen wurden analysiert und verglichen
• Vision_03 wurde als offizieller Design-Baseline festgelegt
• Vision_03 deckt den vollständigen Kern-Workflow ab: Login → Veranstalter → Veranstaltung → Turnier → Nennungen → Startlisten → Ergebnisse
• Fehlende Screens aus Vision_02 (Startlisten, Ergebnislisten, Veranstalter-Flow) sind in Vision_03 vollständig implementiert

2. Technologie-Entscheidung: Desktop-First mit KMP

• Fokus auf Compose Desktop (KMP) als primäre Plattform
• Sharing-Grad: ~100% Business Logic, ~80–90% UI-Komponenten, ~70% Layout/Navigation
• Desktop-App zuerst → Shared Module extrahieren → Web-Portal aufbauen

3. DDD-Analyse: 6 Bounded Contexts (SCS-Architektur)

SCS	Kontext	Priorität
registration-context	Nennungs-Workflow (Herzstück)	P1
actor-context	Reiter, Pferde, Funktionäre, ZNS	P1
competition-context	Bewerbe, Startlisten, Ergebnisse	P2
event-management-context	Veranstaltung, Turnier, Ausschreibung	P2
billing-context	Abrechnung, Kassa, Gebühren	P3
identity-context	Auth, Rollen	P3
series-context	Cups, Serien, Meisterschaften	Phase 2+

4. Terminologie-Klärung (ÖTO § 2 Abs. 1)

• Kritische Korrektur: „Veranstaltung" ≠ „Turnier" in der ÖTO
• Veranstaltung = Oberbegriff (interne ID, selbst vergeben) für alle pferdesportlichen Veranstaltungen
• Turnier = Spezialisierung mit Ausschreibung + OEPS-Turniernummer (§ 2 Abs. 2)
• Eine Veranstaltung kann mehrere Turniere enthalten (z.B. CDN + CSN am selben Wochenende)

5. Meisterschaften / Cups / Serien – Eigene Reglements

• Jede Meisterschaft, jeder Cup und jede Serie besitzt ein eigenes, individuelles Reglement
• Das Reglement ist nicht durch die ÖTO allein abgedeckt
• Kritische Architektur-Konsequenz: series-context muss Reglement als konfigurierbare Entität abbilden (kein Hard-Coding)
• Verschiedene Cups können unterschiedliche Punktesysteme haben → pluggable Berechnungsmodell erforderlich
• Paar-Bindung (Punkte an Reiter+Pferd vs. nur Reiter) ist pro Reglement konfigurierbar

---

Erstellte / Aktualisierte Dokumente

Dokument	Aktion	Beschreibung
docs/03_Domain/01_Glossary/Ubiquitous_Language.md	✅ NEU ERSTELLT	Offizielle Domänen-Terminologie mit ÖTO-Referenzen, Bounded Context Zuordnung, Hierarchie-Diagramm, Reglement-Hinweis für Cups/Serien/Meisterschaften und MVP-Scope-Tabelle
docs/03_Domain/01_Glossary/Ubiquitous_Language.md	✅ KORRIGIERT	Drei Korrekturen eingearbeitet (📜 ÖTO/FEI Rulebook Expert Review): Abteilung als kleinste Einheit für Nennungen/Startlisten/Ergebnisse mit Abteilungsnummer und Referenzformat BW:9 Abt:1; Bewerb korrigiert (nicht mehr „kleinste Einheit"); Kopfnummer als nicht eindeutige ID markiert; Lebensnummer mit Hinweis auf inkonsistente ZNS-Daten ergänzt
core/core-domain/.../Enums.kt	✅ ERWEITERT	Neue Enums: SparteE, TurnierkategorieE, VeranstaltungsTypE, LizenzKlasseE, NennungsStatusE, StartwunschE – alle ÖTO-konform mit KDoc-Kommentaren
backend/services/persons/persons-domain/.../DomReiter.kt	✅ NEU ERSTELLT	Reiter-Domänenmodell (actor-context): Satznummer als ZNS-Primärschlüssel, LizenzKlasse, Startkarte, Sparten-Lizenz, Gastreiter-Flag, validateForNennung() gibt nur Warnungen (kein harter Fehler)
backend/services/entries/entries-domain/.../DomNennung.kt	✅ NEU ERSTELLT	Nennungs-Domänenmodell (registration-context): Referenz auf Abteilung (kleinste Einheit), Reiter, Pferd, Zahler; Nachnennung-Flag, Gebühren-Verzicht, Status-Lifecycle
backend/services/entries/entries-domain/.../DomNennungsTransfer.kt	✅ NEU ERSTELLT	Transfer-Domänenmodell: explizites Audit-Trail (alter/neuer Reiter, altes/neues Pferd), Override-Event-Referenz, isValid() prüft dass mindestens Reiter oder Pferd getauscht wurde
backend/services/entries/entries-domain/build.gradle.kts	✅ NEU ERSTELLT	Neues KMP-Modul nach Muster horses-domain; in settings.gradle.kts registriert; compileKotlinJvm erfolgreich

---

Wichtige Entscheidungen (ADRs)

1. Vision_03 = Design-Baseline für die KMP-Implementierung
2. Desktop-First-Strategie mit KMP/Compose Desktop
3. Veranstaltung ≠ Turnier – Terminologie gemäß ÖTO § 2 Abs. 1 festgelegt
4. 6 Bounded Contexts als SCS-Architektur definiert
5. series-context ist Phase 2+ – Architektur ist aber von Anfang an vorbereitet
6. Cups/Serien/Meisterschaften benötigen eigene, konfigurierbare Reglements

---

Nächste Schritte (Empfehlung)

• 👷 [Backend Developer]: Kotlin Domain-Modelle für registration-context und actor-context definieren
• 🏗️ [Lead Architect]: MASTER_ROADMAP mit den 6 Bounded Contexts aktualisieren → docs/01_Architecture/MASTER_ROADMAP.md
• 🎨 [Frontend Expert]: KMP/Compose Desktop Projektstruktur aufsetzen
• 📜 [ÖTO/FEI Rulebook Expert]: Abteilungs-Trennungs-Schwellenwerte (sparten- und klassenabhängig) recherchieren und dokumentieren → docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md

---

Session-Dauer: ~24. März 2026, ganztägig Curator: Junie (KI-Agent)