Stefan Mogeritsch c624df8744 feat(docs): document DDD session log and establish Ubiquitous Language reference

- Added 2026-03-24 DDD session log covering architecture, terminology, and Ubiquitous Language creation.
- Defined six Bounded Contexts (SCS architecture) and clarified ÖTO-compliant terminology (`Veranstaltung ≠ Turnier`).
- Introduced `Ubiquitous_Language.md` as an official glossary for all domain terms and references.
- Highlighted MVP boundaries and introduced configurable reglements for Cups, Series, and Championships.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>

2026-03-24 16:02:48 +01:00

5.7 KiB

Raw Blame History

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

Wichtige Entscheidungen (ADRs)

Vision_03 = Design-Baseline für die KMP-Implementierung
Desktop-First-Strategie mit KMP/Compose Desktop
Veranstaltung ≠ Turnier – Terminologie gemäß ÖTO § 2 Abs. 1 festgelegt
6 Bounded Contexts als SCS-Architektur definiert
series-context ist Phase 2+ – Architektur ist aber von Anfang an vorbereitet
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
🎨 [Frontend Expert]: KMP/Compose Desktop Projektstruktur aufsetzen
📜 [ÖTO/FEI Rulebook Expert]: Abteilungs-Trennungs-Schwellenwerte (sparten- und klassenabhängig) recherchieren und dokumentieren

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

5.7 KiB Raw Blame History Unescape Escape