- Updated Exposed migration guide with detailed breaking changes, migration steps, test matrix, and rollback plan.
- Published technical analysis for transitioning to Ktor 3.4.0, including API improvements and routing OpenAPI integration.
- Aligned `platform-bom` with upgraded dependencies: `exposed` 1.0.0 and `ktor` 3.4.0.
- Introduced `ktor-server-routing-openapi` dependency for dynamic API documentation support.
Deleted the unused `compose.hardcoded.yaml` file. Updated Gradle build scripts to resolve issues with Jackson and Resilience4j library bundles by explicitly specifying direct dependencies. Removed the `sqldelight` plugin and related dependencies from `local-db` module. Consolidated `docker-compose.yaml` to standardize restart policies. Adjusted `.env` to include cautions for sensitive data and rechecked Java version comments.
- Updated Kotlin compiler and JVM toolchain to target JVM 25 in all subprojects.
- Enforced stable `kotlinx-serialization-json:1.7.3` version to prevent resolution issues.
- Introduced JS bundle size budget checks for frontend shells with gzip support and reporting.
- Refined and reorganized Gradle module includes in `settings.gradle.kts`.
- Removed legacy and redundant dependency configurations for improved clarity.
### Summary
- Removed `repositories` blocks from individual `build.gradle.kts` files, moving configuration to `settings.gradle.kts`.
- Replaced custom Spring Boot constraints in the platform BOM with the Spring Boot BOM for cleaner dependency management.
- Explicitly added `webflux` dependency for Gateway to handle transitivity changes in Spring Boot 4.x.
This commit introduces a major refactoring of the build system and the core infrastructure modules. The primary goal is to establish a strict "Single Source of Truth" for all dependencies using Gradle Version Catalogs and to create a clean, maintainable, and scalable foundation for all current and future services.
### 1. Centralized Dependency Management (`libs.versions.toml`)
- **Established Single Source of Truth:** All dependency versions are now exclusively managed in `gradle/libs.versions.toml`. Hardcoded versions have been removed from all build scripts.
- **Introduced Gradle Bundles:** To simplify module dependencies, several bundles have been created (e.g., `testing-jvm`, `redis-cache`, `spring-cloud-gateway`, `monitoring-client`). This drastically reduces boilerplate in the `build.gradle.kts` files and improves readability.
- **Cleaned up Aliases:** All library and plugin aliases have been standardized for consistency.
### 2. Infrastructure Module Refactoring
All infrastructure modules (`core`, `platform`, `auth`, `cache`, `event-store`, `messaging`, `monitoring`, `gateway`) have been refactored to align with the new dependency management strategy.
- **Simplified Build Scripts:** The `build.gradle.kts` for each module now uses the new bundles and aliases, making them significantly cleaner and easier to understand.
- **Consistent Structure:** The architecture of each module now clearly follows the Port-Adapter pattern where applicable (e.g., `cache-api`/`redis-cache`).
- **Standardized `platform-bom`:** The project's own Bill of Materials (`platform-bom`) now also includes the Spring Cloud BOM, ensuring version consistency for all Spring-related dependencies.
### 3. Added Infrastructure Documentation
To improve onboarding and architectural understanding, a dedicated `README-*.md` file has been created for each refactored infrastructure module:
- `README-CORE.md`
- `README-PLATFORM.md`
- `README-INFRA-AUTH.md`
- `README-INFRA-CACHE.md`
- `README-INFRA-EVENT-STORE.md`
- `README-INFRA-MESSAGING.md`
- `README-INFRA-MONITORING.md`
- `README-INFRA-GATEWAY.md`
These documents explain the purpose, architecture, and usage of each component within the system. This lays the groundwork for our "Tracer Bullet" development approach.
1. **Docker-Compose für Entwicklung optimieren**
2. **Umgebungsvariablen für lokale Entwicklung**
3. **Service-Abhängigkeiten**
4. **Docker-Compose für Produktion**
5. **Dokumentation**
1. **Dokumentation der Architektur:**
- Vervollständigen Sie die C4-Diagramme im docs-Verzeichnis
- Dokumentieren Sie die wichtigsten Architekturentscheidungen in ADRs
2. **Redis-Integration finalisieren:**
- Implementieren Sie die verteilte Cache-Lösung für die Offline-Fähigkeit
- Nutzen Sie Redis Streams für das Event-Sourcing
