stefan df5919fac8 feat(build): Refactor infrastructure modules and establish single source of truth

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.

2025-07-31 14:09:22 +02:00

2.6 KiB

Raw Blame History

Platform Module

Überblick

Das Platform-Modul ist das Rückgrat der Build-Infrastruktur des Meldestelle-Projekts. Seine alleinige Aufgabe ist die zentrale Verwaltung und Bereitstellung von Abhängigkeiten und deren Versionen. Dies stellt sicher, dass alle Module im gesamten Projekt dieselben Bibliotheksversionen verwenden, was Inkonsistenzen ("JAR Hell") verhindert und die Wartbarkeit drastisch verbessert.

Das Modul agiert als eine interne "Single Source of Truth" für alle externen Bibliotheken.

Architektur

Das Platform-Modul ist in drei spezialisierte Untermodule aufgeteilt, die jeweils eine klare Aufgabe haben:

platform/ ├── platform-bom/ # Bill of Materials (BOM) - Erzwingt Versionen ├── platform-dependencies/ # Bündelt gemeinsame Laufzeit-Abhängigkeiten └── platform-testing/ # Bündelt gemeinsame Test-Abhängigkeiten

`platform-bom`

Dies ist das wichtigste Modul der Plattform. Es ist als "Bill of Materials" (BOM) konfiguriert und nutzt das java-platform-Plugin von Gradle.

Zweck: Definiert eine umfassende Liste von Abhängigkeiten und deren exakten, geprüften Versionen. Es importiert auch andere wichtige BOMs (z.B. von Spring Boot und Kotlin).
Funktionsweise: Andere Module importieren diese BOM mit platform(projects.platform.platformBom). Gradle sorgt dann dafür, dass alle transitiven und deklarierten Abhängigkeiten den in der BOM festgelegten Versionen entsprechen.
Vorteil: Absolute Versionskontrolle über das gesamte Projekt.

`platform-dependencies`

Ein einfaches "Sammelmodul", das die am häufigsten benötigten Laufzeit-Abhängigkeiten bündelt.

Zweck: Vereinfacht die build.gradle.kts-Dateien der Service-Module. Anstatt 5-6 einzelne kotlinx- und Logging-Bibliotheken hinzuzufügen, genügt eine einzige Abhängigkeit zu diesem Modul.

Verwendung:

// In einem Service-Modul
dependencies {
    implementation(projects.platform.platformDependencies)
}

`platform-testing`

Analog zu platform-dependencies, aber speziell für Test-Bibliotheken.

Zweck: Stellt ein konsistentes Set an Test-Frameworks (JUnit 5, MockK, AssertJ) und Werkzeugen (Testcontainers) für alle Module bereit.

Verwendung:

// In einem Service-Modul
dependencies {
    testImplementation(projects.platform.platformTesting)
}

Optimierung: Dieses Modul nutzt die in libs.versions.toml definierten [bundles], um die Build-Datei extrem kurz und lesbar zu halten.

Letzte Aktualisierung: 31. Juli 2025

2.6 KiB Raw Blame History