Stefan Mogeritsch
a454e6c97a
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.
64 lines
4.5 KiB
Markdown
64 lines
4.5 KiB
Markdown
### 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:
|
|
|
|
```text
|
|
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?**
|