354bd49de6
- Added `meldestelle-desktop` module using JVM/Compose Desktop, registered in `settings.gradle.kts`. - Integrated new screens and desktop navigation into core: `Veranstaltungen`, `TurnierDetail`, etc. - Expanded backend with `ExposedFunktionaerRepository` in `officials-infrastructure`. - Completed ADRs for bounded context mapping (`ADR-0014`) and context map (`ADR-0015`). - Updated and extended project documentation with session logs and architecture decisions. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
6.4 KiB
6.4 KiB
date, agent, phase, status
| date | agent | phase | status |
|---|---|---|---|
| 2026-03-24 | Backend Developer | PHASE 4 – MVP-Implementierung | ABGESCHLOSSEN |
Session Log: REST-Endpunkte Nennungs-Workflow
👷 [Backend Developer] | 24. März 2026
Ziel
Implementierung der REST-Endpunkte für den Nennungs-Workflow (registration-context) gemäß MASTER_ROADMAP Phase 4.
Erledigte Aufgaben
1. entries-service aktiviert
settings.gradle.kts::backend:services:entries:entries-serviceaus dem ON-HOLD-Kommentar befreit und aktiv eingebunden.
2. entries-api – Fachliche DTOs (NennungDtos.kt)
Neue Datei: entries-api/src/commonMain/kotlin/at/mocode/entries/api/NennungDtos.kt
| DTO | Zweck |
|---|---|
NennungEinreichenRequest |
POST – Neue Nennung einreichen |
NennungStatusAendernRequest |
PUT – Status ändern |
NennungTransferRequest |
POST /transfer – Transfer-Operation |
NennungSummaryDto |
GET Liste – kompakte Ansicht |
NennungDetailDto |
GET Detail / POST Response |
NennungsTransferDto |
Transfer-Response mit Audit-Trail |
Dependency ergänzt: projects.core.coreDomain in entries-api/build.gradle.kts (für NennungsStatusE,
StartwunschE, UuidSerializer).
3. entries-domain – NennungsTransferRepository
Neues Interface: entries-domain/.../repository/NennungsTransferRepository.kt
findById,findByUrsprungsNennungId,save
4. entries-service – Persistence-Schicht
| Datei | Inhalt |
|---|---|
NennungTable.kt |
Exposed-Tabelle nennungen mit allen Feldern + Indizes |
NennungsTransferTable.kt |
Exposed-Tabelle nennungs_transfers mit Audit-Trail |
NennungRepositoryImpl.kt |
Vollständige Implementierung aller NennungRepository-Methoden |
NennungsTransferRepositoryImpl.kt |
Implementierung aller NennungsTransferRepository-Methoden |
5. entries-service – Use Cases (NennungUseCases.kt)
@Service-Klasse mit folgenden Use Cases:
| Methode | Fachliche Logik |
|---|---|
getNennungById |
Query by ID |
getNennungenByTurnier/Bewerb/Abteilung/Reiter |
Gefilterte Listen |
nennungEinreichen |
Neue Nennung, Warn-Log bei Nachnennung |
statusAendern |
Status-Transition mit Audit-Timestamp |
nennungZurueckziehen |
Soft-Delete → Status ZURUECKGEZOGEN |
nennungTransferieren |
Atomare Transfer-Operation (ÖTO-konform): Ursprung → TRANSFERIERT, neue Nennung anlegen, Transfer-Record speichern |
ÖTO-Konformität: Warn-Logik statt harter Fehler. TBA hat das letzte Wort.
6. entries-service – REST-Controller (NennungController.kt)
Basis-URL: /api/v1/registrations/nennungen
| Methode | Endpunkt | Beschreibung |
|---|---|---|
GET |
/ |
Liste (Filter: turnierId, bewerbId, abteilungId, reiterId) |
GET |
/{nennungsId} |
Detail |
POST |
/ |
Neue Nennung einreichen (201) |
PUT |
/{nennungsId}/status |
Status ändern |
DELETE |
/{nennungsId} |
Zurückziehen |
POST |
/{nennungsId}/transfer |
Transfer (201) |
7. entries-service – Konfiguration
| Datei | Inhalt |
|---|---|
EntriesBeansConfiguration.kt |
Spring-Beans für Repository-Implementierungen |
EntriesDatabaseConfiguration.kt |
Exposed-Schema-Init (NennungTable, NennungsTransferTable) |
EntriesExceptionHandler.kt |
RFC 9457 Problem Details (404, 400, 409) |
8. entries-service – Build-Dependencies ergänzt
implementation(projects.backend.services.entries.entriesDomain)
implementation(projects.core.coreUtils)
implementation(projects.core.coreDomain)
implementation(libs.exposed.core)
implementation(libs.exposed.jdbc)
implementation(libs.exposed.kotlin.datetime)
Architektur-Entscheidungen
- Warn-Logik: Nachnennungen und Transfers nach Nennschluss werden geloggt (
log.warn), aber nicht blockiert – gemäß ADR-7 (Warn-Logik statt harter Fehler). - Transfer = atomare Operation: Keine Storno + Neunennung, sondern: Ursprung → TRANSFERIERT + neue Nennung + Transfer-Record. Entspricht ÖTO-Regelwerk.
- Soft-Delete: Nennungen werden nie physisch gelöscht, sondern auf
ZURUECKGEZOGENgesetzt. - Repository-Pattern: Interfaces in
entries-domain, Implementierungen inentries-service(Dependency Inversion).
Nächste Schritte
- ÖTO/FEI Rulebook Expert: Voltigieren (CVN) und Fahren (CAN) Abteilungs-Trennungsregeln auswerten (offene Fragen #3, #4).
- QA Specialist: Integrationstests für den Nennungs-Workflow schreiben.
- Backend Developer:
competition-context(Bewerbe, Startlisten, Ergebnisse) – PHASE 5.