72 lines
3.4 KiB
Markdown
72 lines
3.4 KiB
Markdown
---
|
|
type: Reference
|
|
status: ACTIVE
|
|
owner: Lead Architect
|
|
last_update: 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
|