- Updated `springBoot` to version `4.0.1` for compatibility improvements. - Reactivated and explicitly defined `reactor-kafka` dependency. - Added missing `spring-boot-starter-aop` definition to dependency catalog.
4.5 KiB
Analyse und Strategie zur Wiederherstellung und Strukturverbesserung
Es ist eine klassische Situation: Nach einem großen Technologie-Upgrade (Kotlin 2.1.0+, Java 25, Spring Boot 3.5.x) knirscht es oft an den Schnittstellen. Da dein ping-service als technischer Blueprint dient, ist er der absolut richtige Startpunkt.
Hier ist der Schlachtplan, um Ordnung zu schaffen und die hexagonale Architektur sauber zu etablieren:
1. Wo beginnen? Bottom-Up vs. Top-Down
Da deine Infrastruktur aktuell nicht stabil läuft, empfehle ich einen "Core-First" Ansatz, gefolgt vom Backend-Durchstich.
- Zuerst: Core & Platform: Ohne eine stabile Basis (
platform-bom,platform-dependencies,core-domain) werden die anderen Module immer wieder Kompilierfehler werfen. - Dann: Der technische vertikale Durchstich (
ping-service): Sobald die Plattform steht, reparieren wir den Weg:Infrastruktur (Docker) -> Ping-Service -> Gateway. - Zuletzt: Frontend: Das Frontend (BFF-Gedanke) wird erst dann stabil, wenn die API-Contracts des Backends wieder verlässlich geliefert werden.
2. Ordnung schaffen: Der "Clean Desk" im Projekt
Bevor wir Code fixen, müssen wir die Build-Umgebung aufräumen:
- Version Catalog Synchronität: Deine
libs.versions.tomlnutzt bereits Java 25 und Kotlin 2.1.0. Prüfe, ob alle Gradle-Plugins (insbesondere dascompose-multiplatformundspring-bootPlugin) mit Kotlin 2.1.0 kompatibel sind. Oft ist hier ein Downgrade auf die letzte stabile Version oder ein Upgrade auf Alpha/Beta-Versionen nötig, wenn man "Bleeding Edge" (Java 25) nutzt. - Modul-Konsolidierung (DDD): Wie besprochen, solltest du die "Modul-Explosion" reduzieren.
- Vorschlag: Statt 5 Module pro Domain (
api,common,domain,infrastructure,service), reduziere es auf maximal zwei:domain-api: Nur DTOs und Interfaces (für KMP-Sharing mit dem Frontend).domain-service: Die gesamte Implementierung (Hexagonal strukturiert in Packages).
- Vorschlag: Statt 5 Module pro Domain (
3. Hexagonale Architektur im ping-service umsetzen
Dein ping-service ist aktuell noch sehr "Spring-lastig" (Controller ruft Service mit Circuit Breaker direkt auf). Für eine echte hexagonale Vorlage strukturiere das Modul ping-service intern wie folgt um:
at.mocode.ping.service
├── adapter
│ ├── in
│ │ └── web (PingController - Dein primärer Port-Adapter)
│ └── out
│ └── persistence (PingRepositoryAdapter - Sekundärer Port-Adapter)
├── application
│ ├── port
│ │ ├── in (PingUseCase - Das Interface für den Controller)
│ │ └── out (PingOutputPort - Interface für die Datenbank)
│ └── service (PingService - Hier liegt die Business Logik, OHNE Spring-Annotationen wo möglich)
└── domain
└── model (PingEntity/Value Objects)
Der Vorteil: Wenn du dieses Muster im ping-service einmal sauber hast, kopierst du diese Package-Struktur für registry, events etc.
4. Konkrete Schritte zur Reparatur
Schritt 1: Infrastruktur-Check (Docker) Stelle sicher, dass die Basisdienste laufen. Java 25 benötigt oft neuere Container-Images.
- Check
docker-compose.yaml: Laufen Postgres und Keycloak? ping-serviceapplication.yaml: Aktiviere die Datenbank-Verbindung (JPA), die aktuell noch auskommentiert ist, um den "echten" Test zu ermöglichen.
Schritt 2: Backend API-Gateway Fix
Dein Gateway ist der Wächter. Wenn die Security-Konfiguration (SecurityConfig.kt) wegen Bibliotheks-Änderungen in Spring Security 7/Spring Boot 3.5 hakt, ist das Priorität 1.
- Test: Kannst du den
ping-servicedirekt aufrufen? Wenn ja, funktioniert das Gateway-Routing?
Schritt 3: Frontend (BFF) Anpassung
Nutze das Frontend als Konsument. Wenn du den PingApiClient im Frontend hast, sollte dieser gegen das Gateway (BFF-Pattern) laufen, nicht direkt gegen den Service.
Empfehlung zur Vorgehensweise (Prioritäten):
- Gradle-Build stabilisieren: Alle
:platform:*und:core:*Module müssen mit./gradlew buildfehlerfrei durchlaufen. - Ping-SCS fertigstellen: Implementiere eine minimale Datenbank-Speicherung im
ping-service. Das ist der Beweis, dass die JPA/Hibernate-Konfiguration mit Java 25 harmoniert. - Gateway-Security: Stelle sicher, dass das JWT von Keycloak korrekt zum
ping-servicedurchgereicht wird.
Soll ich dir bei einem dieser spezifischen Schritte (z.B. der hexagonalen Package-Struktur für den Ping-Service) mit konkretem Code helfen?