mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
c086190097
meldestelle/docs/01_Architecture/02_Frontend_Architecture.md
Stefan Mogeritsch c086190097 docs: translate remaining architectural guides to German and standardize formatting 
Translated all remaining English architectural documents into German, including ADRs, guides, release notes, and reference materials. Standardized formatting across translated files, updated section headings, and localized inline comments within code examples for consistency.
2026-03-06 14:02:51 +01:00

3.4 KiB
Raw Blame History

type status owner
Reference ACTIVE Lead Architect

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