chore: remove deprecated horses, clubs, officials, and persons services
- Deleted obsolete modules related to horses, clubs, officials, and persons services, including their configurations, build files, and database provisioning scripts. - Cleaned up associated references in the project structure (e.g., `settings.gradle.kts`). - Removed unused database tables and Spring beans related to these domains. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -0,0 +1,95 @@
|
||||
# Roadmap: System-Konsolidierung & Strategie
|
||||
|
||||
🏗️ **[Lead Architect]** & 🧹 **[Curator]** | 28. März 2026
|
||||
|
||||
## 1. Zusammenfassung
|
||||
|
||||
Dieser Fahrplan beschreibt die Schritte zur Konsolidierung der technischen Basis und die Strategie zur Ausrichtung der
|
||||
Feature-Implementierung an der verfeinerten DDD-Struktur (ADR-0014) sowie der Design-Baseline Vision_03.
|
||||
|
||||
---
|
||||
|
||||
## 2. Abgeschlossene Meilensteine (Letzte Sessions)
|
||||
|
||||
### 🟢 Technische Stabilisierung
|
||||
|
||||
* **Kotlin 2.3.20:** Alle Module wurden auf Kotlin 2.3.20 migriert. Deprecation-Warnungen für `Clock` und `Instant`
|
||||
wurden durch Standardisierung auf `kotlin.time.*` behoben.
|
||||
* **Zentralisierte Serialisierung:** Erstellung der `Serializers.kt` im `core-domain` Modul für `Uuid`, `Instant`,
|
||||
`LocalDate`, `LocalDateTime` und `LocalTime`.
|
||||
* **Exposed Framework:** Fixierung der Exposed-Version auf `1.1.1` für alle Module, um eine stabile Persistenzschicht zu
|
||||
gewährleisten.
|
||||
* **Infrastruktur-Refactoring:** Umzug der `DatabaseFactory` nach `core-utils` (jvmMain) als wiederverwendbare
|
||||
Komponente.
|
||||
|
||||
### 🔵 DDD-Konsolidierung: `master-data-context`
|
||||
|
||||
* **Context-Merge:** Die separaten Services (`clubs`, `persons`, `horses`, `officials`) wurden aufgelöst und im
|
||||
zentralen `master-data-context` vereint.
|
||||
* **ZNS-Importer Verifizierung:** Erfolgreicher Testlauf mit der offiziellen `ZNS.zip`. Ca. 70.000 Datensätze wurden
|
||||
korrekt in die neue Struktur importiert.
|
||||
* **Library of Truth:** Etablierung des `master-data-context` als schreibgeschützte (für Enduser) "Single Source of
|
||||
Truth" für Verbandsdaten.
|
||||
|
||||
### 🟡 Identity Integration
|
||||
|
||||
* **ZNS-Identity Link:** Technische Grundlage im `identity`-Service geschaffen, um System-User (Keycloak) mit
|
||||
offiziellen ZNS-Satznummern zu verknüpfen.
|
||||
* **Profil-Erweiterungen:** Implementierung von `DomProfil` für angereicherte Daten (Logos, Bios), ohne die
|
||||
ZNS-Integrität zu gefährden.
|
||||
|
||||
---
|
||||
|
||||
## 3. Detaillierter Fahrplan (Aktuelle & Nächste Schritte)
|
||||
|
||||
### Phase A: Fundament finalisieren (Status: In Arbeit)
|
||||
|
||||
* [ ] **Repository-Vervollständigung:** Finalisierung der Persistenzmethoden in `masterdata-infrastructure` unter
|
||||
Nutzung der neuen Tabellen.
|
||||
* [ ] **API-Refinement:** Abschluss der REST-Endpunkte für den konsolidierten Master-Data-Context (Länder,
|
||||
Bundesländer, Altersklassen, Plätze).
|
||||
* [ ] **Validierungs-Logik:** Implementierung der Matrizen für Startberechtigungen (Altersklassen/Lizenz-Prüfungen) im
|
||||
Master-Data-Kern.
|
||||
|
||||
### Phase B: Identity & Profil-Erfahrung
|
||||
|
||||
* [ ] **ZNS Link UI:** Erstellung des Frontend-Screens in `meldestelle-desktop`, auf dem User ihre offizielle
|
||||
Satznummer suchen und verknüpfen können.
|
||||
* [ ] **Profil-Verwaltung:** Implementierung der UI-Features zur Pflege der erweiterten Profildaten (Logo-Upload,
|
||||
Kontaktinfo).
|
||||
|
||||
### Phase C: Competition-Context Refinement (§ 39 ÖTO)
|
||||
|
||||
* **Atomarität:** Ausrichtung der Logik auf die **"Abteilung"** als kleinste operative Einheit.
|
||||
* **Automatische Trennung:** Implementierung von Warnungen bei Überschreitung der Starter-Schwellenwerte (z.B. 80
|
||||
Starter Fallback).
|
||||
* **Listen-Generierung:** Umstellung der Tabs 7-8 im Frontend auf Abteilungs-basierte Selektion für Start- und
|
||||
Ergebnislisten.
|
||||
|
||||
### Phase D: Vision_03 Evolution
|
||||
|
||||
* **Integration:** Ersetzen der alten administrativen Screens durch die neuen `v2`-Screens (`VeranstalterAuswahlV2`,
|
||||
`TurnierWizardV2`).
|
||||
* **Billing-Sync:** Portierung der Gebühren-Logik (Nenngebühren, Tierwohl-Euro, Sportförderung) vom Figma React-Prototyp
|
||||
in das KMP `billing-feature`.
|
||||
|
||||
---
|
||||
|
||||
## 4. Bounded Context Map (Konsolidiert)
|
||||
|
||||
| Bounded Context | Verantwortung | Source of Truth |
|
||||
|:----------------|:---------------------------------------------------|:------------------------|
|
||||
| `master-data` | SSOT für Personen, Pferde, Vereine, Regelwerk | ZNS Import / Admin |
|
||||
| `identity` | Auth, Profile, ZNS-Links | Keycloak / Link-Tabelle |
|
||||
| `registration` | Nennungs-Management, Validierung gegen Master-Data | System-Nennungen |
|
||||
| `competition` | Live-Scoring, Abteilungen, Start-/Ergebnislisten | Live-Eingabe |
|
||||
| `billing` | Konten, Gebühren, Kassa | Finanz-Transaktionen |
|
||||
| `event-mgmt` | Turnierstruktur, Konfiguration, Zeitplan | User-Konfiguration |
|
||||
|
||||
---
|
||||
|
||||
## 5. Sofort-Maßnahmen
|
||||
|
||||
1. **Backend:** Letzte Kompilierfehler in `masterdata-infrastructure` beheben.
|
||||
2. **Backend:** ZNS-Linking Endpunkte über die Identity-API bereitstellen.
|
||||
3. **Frontend:** `NennungsMaske` auf die neuen, konsolidierten Masterdata-Endpunkte umstellen.
|
||||
@@ -3,7 +3,7 @@ type: ADR
|
||||
id: ADR-0014
|
||||
status: ACTIVE
|
||||
owner: Lead Architect
|
||||
last_update: 2026-03-24
|
||||
last_update: 2026-03-28
|
||||
---
|
||||
|
||||
# ADR-0014: Bounded Context Mapping (SCS-Architektur)
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
type: Reference
|
||||
status: ACTIVE
|
||||
owner: Lead Architect & ÖTO/FEI Rulebook Expert
|
||||
last_update: 2026-03-24
|
||||
last_update: 2026-03-28
|
||||
sources:
|
||||
- ÖTO 2026, Abschnitt A I, § 2 & § 3 & § 4
|
||||
- Domain Workshop 2026-03-17
|
||||
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-03-28
|
||||
---
|
||||
|
||||
# Session Log: Korrektur der Spring Boot Konfiguration im Masterdata-Modul
|
||||
|
||||
🐧 **[DevOps Engineer]** | 28. März 2026
|
||||
|
||||
## Kontext
|
||||
|
||||
Der Build schlug im Modul `:backend:services:masterdata:masterdata-infrastructure` beim Task `bootJar` fehl, da keine
|
||||
`mainClass` konfiguriert war. Da dieses Modul nur Infrastruktur-Code (Exposed Repositories etc.) bereitstellt und keine
|
||||
eigenständige Spring Boot Application ist, sollte kein `bootJar` (ausführbares JAR) erstellt werden.
|
||||
|
||||
## Erledigte Aufgaben
|
||||
|
||||
### 1. ✅ build.gradle.kts Anpassung
|
||||
|
||||
- Das `spring-boot` Plugin in `masterdata-infrastructure/build.gradle.kts` auf `apply false` gesetzt.
|
||||
- Dadurch wird der `bootJar` Task (der eine Main-Class zwingend erfordert) für dieses Modul nicht mehr registriert.
|
||||
- Der Standard `jar` Task bleibt aktiv und stellt die Library für andere Module zur Verfügung.
|
||||
|
||||
### 2. ✅ Build-Verifizierung
|
||||
|
||||
- Lokaler Build der betroffenen Tasks erfolgreich durchgeführt:
|
||||
- `./gradlew :backend:services:masterdata:masterdata-infrastructure:jar` (Erfolgreich)
|
||||
- `./gradlew :backend:services:masterdata:masterdata-service:bootJar` (Erfolgreich, nutzt die Infrastruktur-Library)
|
||||
- Status: **GRÜN**
|
||||
|
||||
## Technische Änderungen
|
||||
|
||||
### `backend/services/masterdata/masterdata-infrastructure/build.gradle.kts`
|
||||
|
||||
- Geändert: `alias(libs.plugins.spring.boot) apply false`
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
- Prüfung anderer Infrastruktur-Module auf ähnliche Fehlkonfigurationen (redundante `bootJar` Tasks).
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
owner: DevOps Engineer
|
||||
last_update: 2026-03-28
|
||||
---
|
||||
|
||||
# Session Log: Metaspace-Optimierung & Build-Fix
|
||||
|
||||
🐧 **[DevOps Engineer]** | 28. März 2026
|
||||
|
||||
## Kontext
|
||||
|
||||
Der Build schlug in mehreren Modulen mit `java.lang.OutOfMemoryError: Metaspace` fehl.
|
||||
Betroffen waren insbesondere die Kotlin/JS und WASM Kompilationen:
|
||||
|
||||
- `:contracts:ping-api:compileKotlinWasmJs`
|
||||
- `:core:core-domain:compileTestKotlinJs`
|
||||
- `:core:core-utils:compileKotlinJs`
|
||||
|
||||
Die bisherigen Limits (1GB Metaspace) reichten für die komplexe Multiplatform-Struktur nicht mehr aus.
|
||||
|
||||
## Erledigte Aufgaben
|
||||
|
||||
### 1. ✅ Metaspace & Heap Erhöhung
|
||||
|
||||
- Metaspace-Limit für den Kotlin Daemon und den Gradle Daemon von **1GB auf 2GB** erhöht.
|
||||
- Heap-Speicher für den Kotlin Daemon von **4GB auf 6GB** erhöht.
|
||||
- Redundante/widersprüchliche JVM-Argumente in `gradle.properties` harmonisiert.
|
||||
|
||||
### 2. ✅ Build-Verifizierung
|
||||
|
||||
- Lokaler Build der betroffenen Tasks erfolgreich durchgeführt:
|
||||
`./gradlew :contracts:ping-api:compileKotlinWasmJs :core:core-domain:compileTestKotlinJs :core:core-utils:compileKotlinJs --no-daemon`
|
||||
- Status: **GRÜN**
|
||||
|
||||
## Technische Änderungen
|
||||
|
||||
### `gradle.properties`
|
||||
|
||||
- `kotlin.daemon.jvmargs`: `-Xmx6g -XX:MaxMetaspaceSize=2g`
|
||||
- `org.gradle.jvmargs`: `-Xmx6g -Dkotlin.daemon.jvm.options="-Xmx4g" -XX:MaxMetaspaceSize=2g`
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
- Überwachung der CI/CD Pipeline auf ähnliche Ressourcen-Engpässe.
|
||||
- Bei weiteren Problemen: Prüfung, ob `--parallel` in Kombination mit vielen JS-Targets zu hohen Lastspitzen führt.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- `gradle.properties`
|
||||
- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
owner: QA Specialist
|
||||
last_update: 2026-03-28
|
||||
---
|
||||
|
||||
# Session Log: Behebung Flyway Migrations-Fehler (Ping-Service)
|
||||
|
||||
🧐 **[QA Specialist]** | 28. März 2026
|
||||
|
||||
## Kontext
|
||||
|
||||
Der Test-Task `:backend:services:ping:ping-service:test` schlug fehl. Die Ursache war ein `FlywayMigrateException` mit
|
||||
der Meldung `ERROR: relation "ping" already exists`.
|
||||
Dies passierte, weil zwei separate Migrations-Dateien versuchten, die gleiche Tabelle `ping` zu erstellen.
|
||||
|
||||
## Erledigte Aufgaben
|
||||
|
||||
### 1. ✅ Identifizierung des Konflikts
|
||||
|
||||
- `V1__init_ping.sql` enthielt bereits die `CREATE TABLE ping` Anweisung.
|
||||
- `V3__.sql` (vermutlich ein automatisches Relikt oder Fehl-Generat) versuchte die gleiche Tabelle erneut anzulegen.
|
||||
|
||||
### 2. ✅ Bereinigung
|
||||
|
||||
- Die redundante Datei `backend/services/ping/ping-service/src/main/resources/db/migration/V3__.sql` wurde gelöscht.
|
||||
- `V1__init_ping.sql` (Schema) und `V2__seed_data.sql` (Testdaten) bleiben als Basis bestehen.
|
||||
|
||||
### 3. ✅ Test-Verifizierung
|
||||
|
||||
- Ausführung von `./gradlew :backend:services:ping:ping-service:test`
|
||||
- Ergebnis: **BUILD SUCCESSFUL**
|
||||
- Alle Tests (Controller, Service, Repository mit Testcontainers) sind grün.
|
||||
|
||||
## Technische Details
|
||||
|
||||
- Die Warnung bezüglich `sun.misc.Unsafe` (ByteBuddy) in Java 25 wurde zur Kenntnis genommen, blockiert den Build aber
|
||||
nicht und ist ein bekanntes Upstream-Thema bei Spring Boot / Hibernate auf neuesten JDKs.
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
- Überwachung der Schema-Generierung in anderen Services, um ähnliche Duplikate zu vermeiden.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
|
||||
- `backend/services/ping/ping-service/src/main/resources/db/migration/`
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: Journal
|
||||
status: COMPLETED
|
||||
owner: Frontend Expert
|
||||
last_update: 2026-03-28
|
||||
---
|
||||
|
||||
# Session Log: Modernisierung der Tab-Komponenten (Material 3)
|
||||
|
||||
🎨 **[Frontend Expert]** | 28. März 2026
|
||||
|
||||
## Kontext
|
||||
|
||||
Die generische `TabRow`-Komponente aus Material 3 wurde als `@Deprecated` markiert. Gemäß den aktuellen Guidelines muss
|
||||
sie durch `PrimaryTabRow` oder `SecondaryTabRow` ersetzt werden, um eine bessere semantische Trennung und konsistente
|
||||
Visualisierung (Indikatoren, Divider) zu gewährleisten.
|
||||
|
||||
## Erledigte Aufgaben
|
||||
|
||||
### 1. ✅ Ersetzung in `turnier-feature`
|
||||
|
||||
- In `TurnierAbrechnungTab.kt` wurde die `TabRow` für die Sidebar durch `SecondaryTabRow` ersetzt.
|
||||
- Eine fehlerhafte/veraltete `SecondaryTabRow` im Hauptbereich wurde korrigiert und vereinfacht (Entfernung von
|
||||
manuellem `tabIndicatorOffset`).
|
||||
- Redundante und fehlerhafte Hilfsmethoden für `tabIndicatorOffset` wurden entfernt.
|
||||
|
||||
### 2. ✅ Ersetzung in `veranstaltung-feature`
|
||||
|
||||
- In `VeranstaltungUebersichtScreen.kt` wurde die Header-`TabRow` durch `PrimaryTabRow` ersetzt.
|
||||
|
||||
### 3. ✅ Build & Verifizierung
|
||||
|
||||
- Test-Kompilation der betroffenen Module erfolgreich:
|
||||
- `:frontend:features:turnier-feature:compileKotlinJvm`
|
||||
- `:frontend:features:veranstaltung-feature:compileKotlinJvm`
|
||||
- Alle unpräfixierten `TabRow`-Aufrufe im Projekt wurden identifiziert und (wo nötig) migriert.
|
||||
|
||||
## Technische Änderungen
|
||||
|
||||
### `TurnierAbrechnungTab.kt`
|
||||
|
||||
- Wechsel zu `SecondaryTabRow` für Sidebar und Hauptbereich.
|
||||
- Cleanup der Imports und Entfernung von `androidx.compose.material` Relikten.
|
||||
|
||||
### `VeranstaltungUebersichtScreen.kt`
|
||||
|
||||
- Wechsel zu `PrimaryTabRow` für den Haupt-Header.
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
- Prüfung weiterer Screens auf ähnliche Deprecations bei zukünftigen Material 3 Updates.
|
||||
- Visueller Abgleich mit Figma Vision_03 nach der Migration der restlichen UI-Komponenten.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
|
||||
- Material 3 Design Guidelines (Tabs)
|
||||
- `MASTER_ROADMAP.md` (Phase 4: MVP-Implementierung)
|
||||
Reference in New Issue
Block a user