mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
8730ffa7db
meldestelle/docs/01_Architecture/02_Frontend_Architecture.md

3.4 KiB
Raw Blame History

type status owner last_update
Reference ACTIVE Lead Architect 2026-03-15

Frontend-Architektur & Modularisierungsstrategie

Status: ENTWURF Zuletzt aktualisiert: 2026-01-19 Kontext: Migration zu Clean Architecture & Feature-Modulen

1. Übersicht

Die Frontend-Architektur von Meldestelle basiert auf Kotlin Multiplatform (KMP) mit Compose Multiplatform für die Benutzeroberfläche. Wir folgen einem strikten Clean Architecture-Ansatz, um Testbarkeit, Skalierbarkeit und Trennung der Zuständigkeiten sicherzustellen.

2. Modulstruktur

Das Projekt ist in folgende Schichten unterteilt:

2.1 Core-Module (frontend/core)

Wiederverwendbare Komponenten, die unabhängig von spezifischen Geschäftsfunktionen sind.

  • core-network: Zentrale HTTP-Client-Konfiguration (Auth, Logging, ContentNegotiation).
  • core-sync: Generische Synchronisierungslogik (SyncManager, SyncableRepository).
  • core-ui: Gemeinsame UI-Komponenten und Design-System.

2.2 Feature-Module (frontend/features)

Jede Geschäftsdomäne (z.B. ping, auth, events) liegt in ihrem eigenen Modul. Ein Feature-Modul MUSS die Clean Architecture Paketstruktur einhalten:

  • at.mocode.{feature}.feature.domain
    • Entitäten: Reine Datenklassen.
    • Interfaces: Repository-Interfaces, Service-Interfaces.
    • Use Cases: Geschäftslogik (optional, für komplexe Logik).
  • at.mocode.{feature}.feature.data
    • Implementierungen: Repository-Implementierungen, API-Clients.
    • DTOs: Data Transfer Objects (wenn von Domain-Entitäten abweichend).
  • at.mocode.{feature}.feature.presentation
    • ViewModels: Zustandsverwaltung.
    • Screens: Composable-Funktionen.
  • at.mocode.{feature}.feature.di
    • Koin-Modul: Konfiguration der Dependency Injection.

2.3 Shells (frontend/shells)

Anwendungs-Einstiegspunkte, die alles zusammenführen.

  • meldestelle-portal: Die Haupt-Web-/Desktop-Anwendung.

3. Migrationsstrategie (Übergangsphase)

Wir migrieren aktuell von einer monolithischen clients-Paketstruktur zu modularen Feature-Modulen.

Regeln für die Migration:

  1. Neue Features: Müssen direkt in frontend/features/{name} unter Verwendung der Clean Architecture-Struktur implementiert werden.
  2. Bestehende Features: Werden schrittweise migriert.
  3. Koexistenz: Während des Übergangs ist Legacy-Code in clients/ erlaubt, aber als veraltet markiert.
  4. Dependency Injection: Legacy-Code muss die neuen Koin-Module verwenden, sofern verfügbar.
  5. Keine Ghost-Klassen: Klassen nicht duplizieren. Wenn eine Klasse in ein Feature-Modul verschoben wird, muss die alte in clients/ gelöscht werden.

4. Wichtige Entscheidungen (ADRs)

ADR-001: Entkopplung der Sync-Logik

  • Entscheidung: ViewModels dürfen nicht direkt vom SyncManager abhängen.
  • Begründung: Um einfacheres Testen zu ermöglichen und die Komplexität des generischen Sync-Mechanismus zu verbergen.
  • Umsetzung: Ein Domain-Service-Interface (z.B. PingSyncService) einführen, das den SyncManager-Aufruf kapselt.

ADR-002: Feature-Modul-Isolation

  • Entscheidung: Feature-Module sollten nach Möglichkeit nicht direkt voneinander abhängen.
  • Kommunikation: Gemeinsame Core-Module oder lose Kopplung über Interfaces/Events verwenden, wenn modulübergreifende Kommunikation nötig ist.

Freigegeben von: Lead Architect