chore: entferne veraltete Architekturdokumente

Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
2026-05-05 21:22:46 +02:00
parent 6f15ada447
commit 15222b5453
258 changed files with 3388 additions and 6533 deletions
@@ -0,0 +1,89 @@
+---
+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