docs: expand ping-service documentation and add backend startup troubleshooting journal

Enhanced `ping-service` documentation with architectural, implementation, and API details. Added a new journal entry outlining the troubleshooting steps for backend startup issues, including fixes for Dockerfile paths, Gradle build conflicts, and Keycloak pre-build configuration.
This commit is contained in:
2026-01-13 17:41:19 +01:00
parent 0335de7654
commit 7da3fc26d3
5 changed files with 96 additions and 20 deletions
+35 -5
View File
@@ -3,11 +3,41 @@
Diese Seite beschreibt den **aktuellen technischen Stand** des `Ping-Service`.
Sie ist der **stabile Einstiegspunkt** ("technische Wahrheit") für diesen Service.
## Einstieg
Der `ping-service` dient als Health-Check-Endpunkt und als technische Blaupause für die Implementierung von Services nach den Prinzipien der Clean Architecture im "Meldestelle"-Projekt.
* Implementierungs-Report (Historie/Detailanalyse): `docs/90_Reports/Ping-Service_Impl_01-2026.md`
## Architektur & Implementierung
## Ablage-Regel (pro System)
Der Service folgt einem Clean Architecture Ansatz:
* Pro Service gibt es eine stabile Datei unter `docs/04_Backend/Services/`.
* Zeitlich datierte Analysen/Status-Reports liegen unter `docs/90_Reports/`.
* **Driving Adapter:** Der `PingController` (`infrastructure/web`) nimmt HTTP-Anfragen entgegen.
* **Application Port:** Das `PingUseCase` (`application`) definiert die Anwendungslogik.
* **Driven Adapters:** Persistenz-Adapter (nicht im Detail gezeigt) interagieren mit der Datenbank.
Die Implementierung ist vollständig **asynchron** und nutzt **Kotlin Coroutines** und Spring WebFlux.
## API-Definition
Die API-Datenstrukturen (DTOs) und das API-Interface (`PingApi`) sind im KMP-Modul `:contracts:ping-api` definiert, um sie mit dem Frontend zu teilen.
### Wichtigste Endpunkte
Alle Endpunkte sind unter dem Basispfad `/` des Service-Ports (Standard: `8081`) erreichbar.
* `GET /ping/simple`:
* Führt einen einfachen Ping aus, speichert das Ereignis in der Datenbank und gibt eine `PingResponse` zurück.
* `GET /ping/enhanced`:
* Ein erweiterter Ping, der mit einem **Resilience4j Circuit Breaker** abgesichert ist.
* Kann einen Fehler simulieren (`?simulate=true`).
* Gibt eine `EnhancedPingResponse` mit Latenz und Circuit-Breaker-Status zurück.
* `GET /ping/health`:
* Ein einfacher Health-Check, der den Status des Services zurückgibt (`HealthResponse`).
* `GET /ping/history`:
* Gibt eine Liste der letzten Ping-Ereignisse aus der Datenbank zurück.
### Security
Die Endpunkte sind aktuell **nicht** durch Spring Security auf Service-Ebene geschützt. Die Absicherung erfolgt auf Ebene des API-Gateways.
## Historie
Der ursprüngliche Arbeitsauftrag zur Implementierung dieses Services ist unter `docs/90_Reports/Ping-Service_Impl_01-2026.md` zu finden, ist aber **veraltet** und spiegelt nicht mehr den aktuellen Stand wider.