Files
meldestelle/JunieBerichte/Wiederherstellung-Strukturverbesserung_2-1-26.md
T
stefan 097721aca3 chore(dependencies): upgrade Spring Boot to 4.0.1, restore reactor-kafka version, add missing AOP starter
- 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.
2026-01-03 00:36:11 +01:00

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:

  1. Version Catalog Synchronität: Deine libs.versions.toml nutzt bereits Java 25 und Kotlin 2.1.0. Prüfe, ob alle Gradle-Plugins (insbesondere das compose-multiplatform und spring-boot Plugin) 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.
  2. 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).

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-service application.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-service direkt 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):

  1. Gradle-Build stabilisieren: Alle :platform:* und :core:* Module müssen mit ./gradlew build fehlerfrei durchlaufen.
  2. Ping-SCS fertigstellen: Implementiere eine minimale Datenbank-Speicherung im ping-service. Das ist der Beweis, dass die JPA/Hibernate-Konfiguration mit Java 25 harmoniert.
  3. Gateway-Security: Stelle sicher, dass das JWT von Keycloak korrekt zum ping-service durchgereicht wird.

Soll ich dir bei einem dieser spezifischen Schritte (z.B. der hexagonalen Package-Struktur für den Ping-Service) mit konkretem Code helfen?