50 lines
2.7 KiB
Markdown
50 lines
2.7 KiB
Markdown
# 🏗️ Modul-Struktur-Blueprint (Standard-Topologie)
|
|
|
|
**Status:** ARCHITECTURAL STANDARD
|
|
**Ziel:** Elimination von strukturellen Inkonsistenheiten (Kraut & Rüben)
|
|
**Prinzip:** Plug-and-Play Multiplatform-Komponenten
|
|
|
|
## 1. Die Modul-Klassifizierung (The Taxonomy)
|
|
|
|
Jedes Modul im Projekt **muss** einer der folgenden drei Klassen zugeordnet werden. Es gibt keine "unidentifizierten" Module mehr.
|
|
|
|
### 🟢 Klasse A: `CORE_LIBRARY`
|
|
* **Zweck:** Reine Geschäftslogik, Datenmodelle, Hilfsfunktionen (Utils).
|
|
* **Anforderung:** Besteht **ausschließlich** aus `src/commonMain`.
|
|
* **Einsatz:** Keine Plattform-spezifischen Abhängigkeiten erlaubt.
|
|
* **Beispiel:** `:core:database`, `:core:network-models`.
|
|
|
|
### 🔵 Klasse B: `UI_COMPONENT` (Der Standard)
|
|
* **Zweck:** Visuelle Features, Screens, interaktive Elemente.
|
|
* **Anforderung:** **Zwingende** Struktur:
|
|
* `src/commonMain` (Logik & Interface)
|
|
* `src/jvmMain` (Desktop-spezifische UI-Erweiterungen/Render-Strategie)
|
|
* `src/wasmJsMain` (Web-spezifische Render-Strategie)
|
|
* **Einsatz:** Das Standard-Modul für alle "Plug-and-Play" Features.
|
|
* **Beispiel:** `:features:auth`, `:features:import`, `:features:settings`.
|
|
|
|
### 🟡 Klasse C: `PLATFORM_ADAPTER`
|
|
* **Zweck:** Tiefe Integration von Hardware-APIs oder Plattform-spezifischem Code.
|
|
* **Anforderung:** Enthält hochgradig spezialisierten Code für eine einzige Plattform.
|
|
* **Beispiel:** `:platform:android-biometrics`.
|
|
|
|
---
|
|
|
|
## 2. Design-Regeln (The Golden Rules)
|
|
|
|
1. **The "Expect/Actual" Rule:** `expect`-Deklarationen gehören immer in den `commonMain`-Source-Set. `actual`-Implementierungen werden strikt in den jeweiligen Plattform-Source-Sets (`jvmMain`, `wasmJsMain`, etc.) platziert.
|
|
2. **The Dependency Rule:** Ein `commonMain`-Modul darf niemals eine Abhängigkeit zu einem Modul haben, das nur in `jvmMain` existiert. Abhängigkeiten müssen immer "nach unten" (zu `common`) oder "horizontal" (zu anderen `common`-Modulen) verlaufen.
|
|
3. **The Consistency Rule:** Ein Modul darf niemals "unvollständig" sein. Wenn ein Modul ein `jvmMain` hat, muss es auch ein `wasmJsMain` (oder zumindest die Infrastruktur dafür) vorbereitet haben, um die Plugin-Architektur nicht zu brechen.
|
|
|
|
---
|
|
|
|
## 3. Implementierungs-Checkliste (Migration Guide)
|
|
|
|
Wenn du ein neues Modul erstellst oder ein altes migrierst:
|
|
|
|
- [ ] Identifiziere die Klasse (A, B oder C).
|
|
- [ ] Erstelle die Verzeichnisstruktur gemäß der Klasse.
|
|
- [ ] Überprüfe die `build.gradle.kts` auf korrekte Source-Set-Konfiguration.
|
|
- [ ] Sicherstellen, dass alle `expect`-Funktionen durch `actual`-Implementierungen in allen Ziel-Plattformen abgedeckt sind.
|
|
- [ ] Teste die Kompilierung für alle Ziel-Plattformen (`./gradlew check`).
|