mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
eea022b862
meldestelle/docs/temp/MODULE_STRUCTURE_BLUEPRINT.md

2.7 KiB
Raw Blame History

🏗️ 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).