mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
35da070893
meldestelle/docs/adr/0009-final-kmp-architecture.md
StefanMoCoAt 14770003bd chore(MP-30): final docs cleanup, adr consolidation & legacy removal 
Summary
- **Documentation Cleanup:**
  - ADRs consolidated to `docs/adr/`.
  - C4 diagrams moved to `docs/c4/`.
  - Removed legacy folder `docs/architecture/` and `docs/clients/`.
- **New ADR:** Added `0009-final-kmp-architecture.md` (Accepted).
- **Updates:**
  - `ARCHITECTURE.md` updated with final folder structure (Core Modules).
  - `README.md` links fixed.
- **Verification:**
  - `./gradlew staticAnalysis` -> SUCCESS.
  - Path references checked.

Ref: MP-30
2025-12-08 18:04:44 +01:00

1.9 KiB
Raw Blame History

ADR-0009: Final KMP Architecture

Status: Accepted

Kontext

Wir schließen die Architektur-Entscheidungen für das Frontend als Kotlin Multiplatform (KMP) Projekt ab und bestätigen die finalen Bausteine sowie die Modulaufteilung. Die Plattformen Web (JS/WASM) und JVM/Desktop werden unterstützt.

Entscheidung

  1. Plattformen: Kotlin Multiplatform mit Targets Web (JS/WASM) und JVM/Desktop.
  2. Dependency Injection: Koin als DI-Framework für gemeinsame und plattformspezifische Layer.
  3. Persistenz (Offline-First): SQLDelight als lokale Datenbank (Single Source of Truth), synchronisiert im Hintergrund.
  4. Modulaufteilung im Frontend:
    • shells: Ausführbare App-Shells (Bootstrap/Assembler, DI-Start, Plattformintegration)
    • features: Vertikale Slices mit UI, Domain-Logik und Navigation pro Feature
    • core: Gemeinsame Basis (design-system, domain, network, local-db, navigation)
  5. Kommunikation: Features reden nicht direkt miteinander; Navigation + Shared-Domain-Modelle in core/domain.

Begründung

  • KMP erlaubt maximale Codewiederverwendung über Web und JVM bei konsistentem Tooling.
  • Koin bietet leichtgewichtige, idiomatische DI ohne Code-Generierung, geeignet für KMP.
  • SQLDelight liefert typsichere Queries, portable Schemas und ist für Offline-First praxiserprobt.
  • Die Trennung in shells/features/core fördert klare Zuständigkeiten, Testbarkeit und schrittweise Erweiterbarkeit.

Konsequenzen

  • Projektstruktur und Gradle-Module folgen strikt der Aufteilung in shells, features, core.
  • Der apiClient (core/network) wird via Koin als Named Binding injiziert; manuelles Setzen von Authorization-Headern ist untersagt.
  • UI liest aus der lokalen Datenbank (SQLDelight); Synchronisation erfolgt über Hintergrundjobs.

Status / Nacharbeiten

  • Diese ADR konsolidiert die KMP-Entscheidung und ersetzt frühere verstreute Notizen. Weitere Details (z. B. konkrete Module, Pfade) sind in docs/ARCHITECTURE.md dokumentiert.