---
date: 2026-03-24
agent: Backend Developer
phase: PHASE 4 – MVP-Implementierung
status: 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

```kotlin
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.