56 lines
2.6 KiB
Markdown
56 lines
2.6 KiB
Markdown
# 🏗️ 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:
|
|
1. **Define** `expect class/function` in `commonMain`.
|
|
2. **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.
|
|
|
|
---
|