meldestelle/_backup/JunieBerichte/Wiederherstellung-Strukturverbesserung_2-1-26.md
Stefan Mogeritsch a454e6c97a docs: restructure domain documentation and update references
Implemented a standardized folder structure for domain documentation to improve clarity and maintainability. Migrated existing files to the new structure, updated links in related documentation, and added README files for navigation and guidance.
2026-01-15 13:44:49 +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?