Add new chat session and extend Gemini conversation: document architecture discussions, domain model updates, Dom prefix removal plan, and phase-based roadmap for Bewerb and related entities.
This commit is contained in:
@@ -468,7 +468,9 @@ Denken Sie z.B. an:
|
||||
• Müssen wir eintragen, an welchem Tag oder auf welchem Platz der Bewerb stattfindet?
|
||||
• Brauchen wir ein Flag für "Qualifikation für Meisterschaft XY"?
|
||||
|
||||
--- Ich ---
|
||||
---
|
||||
Ich
|
||||
---
|
||||
|
||||
Bring mich nocht aus dem Konzept in dem du mir schon so viele Sachen vorlegst.
|
||||
Darum geht es hier ja, um's "Querdenken"
|
||||
@@ -946,3 +948,147 @@ Dann auch noch hinterfragen, ob es so klever ist, die ganzen Klassen immer mit `
|
||||
`DomBewerb` ist hierbei nur als vertreter Beispiel für alle Dom... Klassen Bezeichungen.
|
||||
|
||||
Und dann, hätte ich gerne einen genauen Umsetzungsplan.
|
||||
|
||||
---
|
||||
Neuer Chat-Verlauf 8. April 2026
|
||||
---
|
||||
|
||||
---
|
||||
Ich
|
||||
---
|
||||
Datum: 8. April 2026
|
||||
Wir hatten gestern und heute Vormittag einen super Run im Bezug der Planung und Weiterentwicklung.
|
||||
|
||||
Hier unser Chat-verlauf:
|
||||
"docs/temp/Chat-Verlauf-Gemini_2026-04-07.md"
|
||||
|
||||
Können wir fortfahren?
|
||||
|
||||
---
|
||||
Gemini
|
||||
---
|
||||
|
||||
🏗️ [Lead Architect]
|
||||
|
||||
Ja, absolut! Das war ein fantastischer Deep-Dive und wir haben jetzt ein extrem solides, praxisnahes Fundament.
|
||||
Lassen Sie uns direkt an Ihren letzten drei Punkten anknüpfen:
|
||||
1. Visualisierung
|
||||
Ich habe gesehen, dass die Visualisierung bereits als Kernentitaeten_Umbenennung.puml im C4-Verzeichnis abgelegt wurde. Sie zeigt exakt die Beziehungen auf: Wie die Veranstaltung als "Klammer" dient (für Austragungsplätze und Preislisten), wie das Turnier die offiziellen Rahmendaten hält und wie der Bewerb alle sportlichen Details (inkl. Richter und Abteilungen) bündelt.
|
||||
2. Das Dom-Präfix (Namenskonvention)
|
||||
Ihre Intuition ist 100 % richtig. In einer sauberen Clean Architecture ist die Domäne das Zentrum der Anwendung. Die wichtigsten Kern-Klassen sollten die "saubersten" Namen haben.
|
||||
•
|
||||
Richtig: Bewerb, Turnier, Veranstaltung (im Domain-Layer)
|
||||
•
|
||||
Außen: BewerbEntity oder BewerbTable (im Infrastruktur/Datenbank-Layer) und BewerbDto (im API/Web-Layer).
|
||||
Das ständige Dom-Präfix ist ein Relikt und wir werden es als allerersten Schritt im Umsetzungsplan entfernen, um den Code lesbarer und professioneller zu machen.
|
||||
3. Der genaue Umsetzungsplan
|
||||
|
||||
Hier ist der detaillierte Masterplan (Roadmap) für die nächsten Entwicklungs-Sprints. Wir teilen das in logische, gut testbare Pakete (PRs/Stints) auf:
|
||||
|
||||
### 🟢 Phase 1: Clean-Up & Refactoring (Fokus: Domain)
|
||||
|
||||
Agent: 👷 [Backend Developer]
|
||||
1. **Umbenennung:** Alle `Dom...` Klassen im Core- und Events/Entries-Domain-Modul in ihre sauberen Namen umbenennen (z.B. `DomBewerb` -> `Bewerb`, `DomTurnier` -> `Turnier`).
|
||||
2. **Enums erweitern:**
|
||||
- `AbteilungsTeilungsTypE` um den Wert `MANUELL` ergänzen.
|
||||
- Neues Enum `BeginnZeitTypE` (`FIX`, `ANSCHLIESSEND`) anlegen.
|
||||
|
||||
### 🟡 Phase 2: Domain-Erweiterung (Fokus: Plätze, Richter & Bewerbs-Details)
|
||||
|
||||
Agent: 👷 [Backend Developer]
|
||||
1. **Veranstaltungsebene:**
|
||||
- Neues Modell `Austragungsplatz` (ID, Name, Typ, Sparte optional) erstellen.
|
||||
- Neues Modell `TurnierArtikel` (Preisliste für Heu, Ansage etc.) erstellen.
|
||||
2. **Bewerbsebene:**
|
||||
- `Bewerb` um textliche Details erweitern: `beschreibung`, `aufgabe`, `aufgabenNummer`, `paraGrade`.
|
||||
- `Bewerb` um Zeitplan-Felder erweitern: `austragungsplatzId`, `geplantesDatum`, `beginnZeitTyp`, `beginnZeit`, `reitdauerMinuten`, `umbauMinuten`, `besichtigungMinuten`, `stechenGeplant`.
|
||||
- `Bewerb` um finanzielle Felder erweitern: `startgeldCent`, `geldpreisAusbezahlt`.
|
||||
3. **Richter-Einsatz:**
|
||||
- Neues Value-Object `RichterEinsatz` (funktionaerId, position) erstellen und als Liste dem Bewerb hinzufügen.
|
||||
|
||||
### 🟠 Phase 3: Persistenz & Datenbank (Fokus: Infrastruktur)
|
||||
|
||||
Agent: 👷 [Backend Developer]
|
||||
1. **Neue Tabellen:** Flyway-Migrationen für `austragungsplaetze`, `turnier_artikel` und `richter_einsaetze` (Mapping-Tabelle zu Bewerben) schreiben.
|
||||
2. **Bewerb-Tabelle:** Flyway-Migration schreiben, um `bewerbe` um die zahlreichen neuen Spalten (Aufgabe, Zeiten, Geldpreis etc.) zu erweitern.
|
||||
3. **Repositories:** Die `RepositoryImpl`-Klassen anpassen, damit alle neuen Felder und Listen beim Speichern und Laden korrekt gemappt werden.
|
||||
|
||||
### 🔵 Phase 4: API & Frontend-Wizard (Fokus: User Experience)
|
||||
|
||||
Agenten: 👷 [Backend Developer] & 🎨 [Frontend Expert]
|
||||
1. **API-DTOs:** Die Request/Response-Objekte (`CreateBewerbDto`, etc.) um die neuen Felder aktualisieren.
|
||||
2. **Frontend UI:** Den "Neuer Bewerb"-Wizard in Compose Multiplatform bauen (angelehnt an die SuDo-Screenshots):
|
||||
- **Tab/Step 1:** Identifikation (Sparte, Kategorie, Klasse, Bezeichnung).
|
||||
- **Tab/Step 2:** Details (Aufgabe, Beschreibung, Geldpreis).
|
||||
- **Tab/Step 3:** Ort & Zeit (Austragungsplatz-Dropdown, Zeiten-Kalkulation).
|
||||
- **Tab/Step 4:** Richter-Zuweisung (inkl. der "Warn-Logik" für Qualifikationen, falls diese nicht zwingend passen, aber vom TB erlaubt werden).
|
||||
|
||||
---
|
||||
|
||||
**Wie wollen wir starten?** Soll ich direkt den 👷 [Backend Developer] instruieren, mit Phase 1 (Umbenennung der Dom-Klassen) loszulegen, damit wir das Fundament bereinigt haben, bevor wir die neuen Felder einbauen?
|
||||
|
||||
---
|
||||
Ich
|
||||
---
|
||||
|
||||
Schreibe mir einen genauen Prompt für:
|
||||
- 🏗️ [Lead Architect] &
|
||||
- 👷 [Backend Developer]
|
||||
|
||||
Dann werde ich es gleich veranlassen.
|
||||
|
||||
---
|
||||
Gemini
|
||||
---
|
||||
|
||||
Hier ist der exakte Prompt für den Lead Architect und den Backend Developer. Sie können diesen Text einfach kopieren und in der nächsten Nachricht (oder einer neuen Session) abschicken, um die Umsetzung der ersten beiden Phasen zu starten.
|
||||
|
||||
```markdown
|
||||
# 🤖 Project Agents & Protocol: Phase 1 & 2 – Domain-Clean-Up & Modell-Erweiterungen
|
||||
|
||||
🏗️ **@Lead Architect** & 👷 **@Backend Developer**
|
||||
|
||||
Bitte führt gemeinsam das folgende Architektur-Update durch. Wir haben in unserer letzten Analyse festgestellt, dass unsere Kern-Domäne noch Relikte in der Namensgebung (`Dom`-Präfix) enthält und wichtige fachliche Felder (aus dem ÖTO-Regelwerk und der Meldestellen-Praxis) am `Bewerb` und der `Veranstaltung` fehlen.
|
||||
|
||||
**Kontext:**
|
||||
Das Ziel ist eine saubere *Clean Architecture*, in der die Domain-Klassen ihre echten, fachlichen Namen tragen (z.B. `Bewerb` statt `DomBewerb`). Darauf aufbauend müssen wir die Modelle für den künftigen "Neuer Bewerb"-Wizard erweitern (Austragungsplätze, Zeitplan, Richter, Aufgaben). Die visuelle Ziel-Architektur findet sich in `docs/01_Architecture/c4/Kernentitaeten_Umbenennung.puml`.
|
||||
|
||||
## 🏗️ Aufgaben für [Lead Architect]
|
||||
* **Ubiquitous Language & Roadmap:**
|
||||
* Überprüfe das Glossar (`docs/03_Domain/01_Glossary/Ubiquitous_Language.md`) und stelle sicher, dass die Bezeichnungen `Austragungsplatz`, `Vorbereitungsplatz`, `RichterEinsatz` und `TurnierArtikel` dokumentiert sind.
|
||||
* Füge der Dokumentation den Architektur-Beschluss hinzu, dass Domain-Entitäten ab sofort **ohne** Präfix (`Dom...`) benannt werden (z.B. als ADR oder in den Coding-Guidelines).
|
||||
|
||||
## 👷 Aufgaben für [Backend Developer]
|
||||
Bitte führe die folgenden Refactorings und Code-Erweiterungen Schritt für Schritt durch und nutze deine Tools (z.B. `find_usages`, `write_file`, `git`), um die Änderungen systemweit sicherzustellen:
|
||||
|
||||
**1. Clean-Up & Renaming (Das `Dom`-Präfix entfernen):**
|
||||
Finde alle Vorkommen der folgenden Kern-Klassen in den Domain-, Service- und Controller-Modulen und benenne sie um. (Achte auf saubere Imports und Variablen-Namen, die ggf. angepasst werden müssen):
|
||||
* `DomVeranstaltung` ➡️ `Veranstaltung`
|
||||
* `DomTurnier` ➡️ `Turnier`
|
||||
* `DomAusschreibung` ➡️ `Ausschreibung`
|
||||
* `DomBewerb` ➡️ `Bewerb`
|
||||
* `DomAbteilung` ➡️ `Abteilung`
|
||||
* `DomNennung` ➡️ `Nennung`
|
||||
* `DomNennungsTransfer` ➡️ `NennungsTransfer`
|
||||
|
||||
**2. Enums erweitern (`core-domain/src/.../Enums.kt`):**
|
||||
* Erweitere das Enum `AbteilungsTeilungsTypE` um den Wert `MANUELL`.
|
||||
* Lege ein neues Enum `BeginnZeitTypE` an, mit den Werten `FIX` und `ANSCHLIESSEND`.
|
||||
|
||||
**3. Neue Modelle anlegen (`events-domain` bzw. relevanter Kontext):**
|
||||
* Erstelle die Klasse `Austragungsplatz` (Felder: `id: UUID`, `name: String`, `typ: String` [z.B. Austragungsplatz/Vorbereitungsplatz], `sparte: SparteE?`).
|
||||
* Erstelle das Value-Object `RichterEinsatz` (Felder: `funktionaerId: UUID`, `position: String`).
|
||||
* *(Optional für Billing)* Erstelle die Klasse `TurnierArtikel` (Felder: `id: UUID`, `name: String`, `preis: Long` (in Cent), `typ: String` [AUTOMATISCH/MANUELL]).
|
||||
|
||||
**4. `Bewerb` (ehemals `DomBewerb`) stark erweitern:**
|
||||
Füge folgende Felder in die Domain-Entität `Bewerb` ein:
|
||||
* **Text & Details:** `beschreibung: String?`, `aufgabe: String?`, `aufgabenNummer: String?`, `paraGrade: String?`
|
||||
* **Ort & Funktionäre:** `austragungsplatzId: UUID?`, `richterEinsaetze: List<RichterEinsatz> = emptyList()`
|
||||
* **Zeitplan:** `geplantesDatum: LocalDate?`, `beginnZeitTyp: BeginnZeitTypE?`, `beginnZeit: LocalTime?`, `reitdauerMinuten: Int?`, `umbauMinuten: Int?`, `besichtigungMinuten: Int?`, `stechenGeplant: Boolean = false`
|
||||
* **Finanzen:** `startgeldCent: Long?`, `geldpreisAusbezahlt: Boolean = false`
|
||||
|
||||
**5. Kompilieren & Checken:**
|
||||
Stelle sicher, dass nach diesen massiven Änderungen im Domain-Modell das Projekt (insbesondere der `entries-service` bzw. `events-service`, in denen diese Klassen verwendet werden) erfolgreich baut. Datenbank-Migrationen (Flyway) und Repository-Mappings machen wir in einem separaten Schritt (Phase 3), sobald das Domain-Modell fehlerfrei steht.
|
||||
|
||||
Bitte meldet euch mit einem Summary zurück, sobald Phase 1 & 2 (Clean-Up & Domain-Modell) erfolgreich abgeschlossen und kompiliert sind!
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user