---
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