chore(build, dependencies): add Room support with KSP integration and optimize testing dependencies

- Integrated Room plugin and runtime dependencies into `local-db` module, including schema configuration for Room.
- Added KSP processor dependencies for Kotlin Multiplatform compatibility.
- Enhanced `core-domain` module by refining and temporarily adjusting testing dependencies for resolution issues.
This commit is contained in:
2026-01-15 19:31:58 +01:00
parent f6e644d433
commit 36aea11ce4
2 changed files with 82 additions and 0 deletions
@@ -0,0 +1,46 @@
# Open-Source-Konformität & Lizenz-Checkliste
Dieses Dokument dient der Überwachung und Sicherstellung der Open-Source-Konformität des Projekts **Meldestelle**. Es wird vom Lead Architect gepflegt.
## Status der Kern-Komponenten (Stand: Januar 2026)
| Komponente | Lizenz | Status | Risiko | Maßnahme / Kommentar |
| :--- | :--- | :--- | :--- | :--- |
| **Kotlin / JVM** | Apache 2.0 / GPLv2+CE | ✅ OK | Sehr gering | Standard-Stack. |
| **Spring Boot / Cloud** | Apache 2.0 | ✅ OK | Sehr gering | |
| **PostgreSQL** | PostgreSQL (BSD-like) | ✅ OK | Sehr gering | |
| **Redis** | **RSALv2 / SSPL** | ⚠️ KRITISCH | Hoch | **Umstieg auf Valkey (BSD) geplant.** |
| **Consul** | **BSL 1.1** | ⚠️ BEOBACHTEN | Mittel | Lizenzänderung durch HashiCorp. Für interne Nutzung aktuell unkritisch. |
| **Keycloak** | Apache 2.0 | ✅ OK | Gering | |
| **SQLDelight** | Apache 2.0 | ✅ OK | Sehr gering | |
| **Redisson** | Apache 2.0 (Core) | ✅ OK | Gering | Sicherstellen, dass keine PRO-Features genutzt werden. |
---
## Checkliste für neue Abhängigkeiten
Bevor eine neue Bibliothek oder Infrastruktur-Komponente hinzugefügt wird, muss sie folgende Kriterien erfüllen:
1. **Lizenz-Typ:**
* Bevorzugt: Apache 2.0, MIT, BSD (3-Clause).
* Akzeptabel: MPL 2.0.
* Einzelfallprüfung: LGPL (nur als dynamische Bibliothek).
* **Verboten:** AGPL, SSPL, RSAL, BSL (sofern nicht explizit vom Architect freigegeben).
2. **Community & Governance:**
* Wird das Projekt von einer neutralen Foundation (Apache, CNCF, Linux Foundation) verwaltet?
* Gibt es eine "Single Vendor" Abhängigkeit (Risiko einer plötzlichen Lizenzänderung)?
3. **Transitive Abhängigkeiten:**
* Bringt die Bibliothek "versteckte" Copyleft-Lizenzen mit? (Check via Gradle License Plugin).
---
## TODOs & Strategische Entscheidungen
- [ ] **Migration Redis -> Valkey:** Umstellung der Docker-Images und Test der Kompatibilität.
- [ ] **Consul Review:** Jährliche Prüfung der BSL-Auswirkungen auf unser Deployment-Modell.
- [ ] **Automatisierung:** Integration eines License-Check-Plugins in den CI-Build (z.B. `com.github.jk1.dependency-license-report`).
---
*Dieses Dokument ist Teil der "Docs-as-Code" Strategie und muss bei jeder Änderung am Tech-Stack aktualisiert werden.*
+36
View File
@@ -0,0 +1,36 @@
# Backend Roadmap - Meldestelle
Dieses Dokument beschreibt die geplanten Schritte zur Weiterentwicklung der Backend-Infrastruktur. Der aktuelle Fokus liegt auf der **Härtung der Infrastruktur** unter Nutzung des `ping-service` als technischem Blueprint.
## Status Quo
* **Blueprint:** `ping-service` ist funktional, dient aber nun als Zielobjekt für Infrastruktur-Verbesserungen.
* **Technologie:** Spring Boot 3.5.9, Kotlin Coroutines, PostgreSQL.
## Meilensteine (Priorisiert)
### Meilenstein 1: Infrastruktur-Härtung (Fokus: Ping-Service)
* [ ] **Observability & Monitoring:**
* Vollständige Integration von Spring Boot Actuator.
* Konfiguration von Micrometer/Prometheus Metriken.
* Logging-Standardisierung (Structured Logging/JSON für ELK/Loki).
* [ ] **Security Baseline:**
* Integration von Spring Security mit Keycloak (OAuth2/OIDC).
* Absicherung der Endpunkte im `ping-service` (RBAC).
* Validierung der JWT-Tokens am API-Gateway.
* [ ] **Resilience & Stability:**
* Härtung des Resilience4j Setups (Circuit Breaker, Bulkhead, Rate Limiter).
* Optimierung der Datenbank-Connection-Pools (HikariCP).
* Einführung von Flyway oder Liquibase für kontrollierte DB-Migrationen.
### Meilenstein 2: Build-System & CI/CD Readiness
* [ ] **Gradle Refactoring:** Umstellung auf Version Catalog (`libs.versions.toml`) für alle Backend-Module.
* [ ] **Test-Härtung:** Standardisierung der Integrationstests mit Testcontainers (Postgres, Keycloak, Redis).
* [ ] **Docker-Optimierung:** Multi-stage Builds und Distroless-Images für reduzierte Angriffsfläche.
### Meilenstein 3: Rollout auf Fach-Services
* [ ] Übertragung der gehärteten Standards vom `ping-service` auf `horses`, `members`, etc.
* [ ] Dokumentation der "Production Readiness Checklist" für neue Services.
## Nächste Schritte (Vorschlag)
1. **Audit des aktuellen `ping-service`:** Identifikation von Lücken in Security und Monitoring.
2. **Zentralisierung der Abhängigkeiten:** Einführung der `libs.versions.toml`, um eine konsistente Basis für die Härtung zu haben.