🏗️ Module Architecture Blueprint

Dieses Dokument definiert die Architektur-Standards für das Projekt, um eine konsistente, skalierbare und wartbare Modulstruktur zu gewährleisten.

🎯 Kernziel

Etablierung einer klaren Trennung zwischen Geschäftslogik (Common) und Plattform-spezifischer Darstellung (JVM/Web), um die Wiederverwendbarkeit und Testbarkeit zu maximieren.

📂 Modultypen (Module Archetypes)

Jedes Modul im Projekt muss einer der folgenden drei Kategorien zugeordnet werden:

1. Core Modules (Type: `CORE`)

Zweck: Rein geschäftliche Logik, Domain-Modelle, Use-Cases.
Struktur: Ausschließlich commonMain. Keine Abhängigkeiten zu Plattform-spezifischen APIs.
Regel: Darf keine Kenntnis über die UI oder Plattform-spezifische Frameworks haben.

2. Feature Modules (Type: `FEATURE`)

Zweck: Implementierung einer spezifischen Benutzerfunktion (z.B. "Login", "Registration").
Struktur: commonMain (Logik) + jvmMain / jsMain (UI/Integration).
Regel: Nutzt CORE-Module. Darf nur über definierte Schnittstellen mit anderen FEATURE-Modulen kommunizieren.

3. Infrastructure/Adapter Modules (Type: `ADAPTER`)

Zweck: Implementierung von Schnittstellen (z.B. API-Clients, Datenbank-Treiber, Bluetooth-Adapter).
Struktur: Implementiert expect-Deklarationen aus CORE oder FEATURE mittels actual-Implementierungen.
Regel: Versteckt die Komplexität der Plattform hinter einer saubbar definierten API.

🛠️ Strukturregeln (The Golden Rules)

📏 Rule 1: Dependency Direction

Abhängigkeiten dürfen nur nach unten fließen: FEATURE \rightarrow CORE \rightarrow ADAPTER (Interfaces) FEATURE \rightarrow ADAPTER (Implementations)

Verboten: Ein CORE-Modul darf niemals ein FEATURE-Modul referenzieren.

🔄 Rule 2: The Expect/Actual Pattern

Um Plattform-spezifischen Code in commonMain nutzbar zu machen, ist das expect/actual-Pattern zwingend:

Define expect class/function in commonMain.
Implement actual class/function in jvmMain (Desktop) und jsMain (Web).

📦 Rule 3: Encapsulation

Module müssen ihre internen Implementierungen verbergen. Nur Klassen und Funktionen, die explizit für die Nutzung durch andere Module markiert sind (z.B. via internal Modifier), dürfen exportiert werden.

🚀 Deployment & Build

Build System: Gradle.
Multiplatform: Kotlin Multiplatform (KMP).
CI/CD Check: Bei jedem Pull-Request wird die Einhardung der Abhängigkeitsrichtung durch ein Dependency-Analysis-Plugin geprüft.

2.6 KiB Raw Blame History