Files
meldestelle/docs/99_Journal/2026-03-24_Session_Log_Nennung_REST_API.md
T
stefan 354bd49de6 feat: integrate new desktop shell and extend backend & ADRs
- 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>
2026-03-24 18:22:15 +01:00

6.4 KiB
Raw Blame History

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-service aus 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 ZURUECKGEZOGEN gesetzt.
  • Repository-Pattern: Interfaces in entries-domain, Implementierungen in entries-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.