48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
# ADR-0024: Plug-and-Play Komponenten-Architektur für Multiplattform-Stabilität
|
|
|
|
## Status
|
|
|
|
Akzeptiert
|
|
|
|
## Kontext
|
|
|
|
Das Projekt "Meldestelle" strebt eine Multiplattform-Anwendung (KMP) für Desktop, Web und Mobile an. Jüngste
|
|
Stabilitätsprobleme im Frontend (der "Kartenhaus-Effekt") wurden durch eng gekoppelte UI-Komponenten und Screens
|
|
verursacht. Änderungen in einem Bereich (z.B. Routing) führten zu Zusammenbrüchen in nicht verwandten Features.
|
|
|
|
## Entscheidung
|
|
|
|
Wir führen eine "Plug-and-Play"-Architektur für alle Frontend-Komponenten ein. Diese Strategie stellt sicher, dass
|
|
Komponenten in sich geschlossen, wiederverwendbar und unabhängig von ihrer Platzierung in der UI-Hierarchie sind.
|
|
|
|
### 1. Atomic Design Ebenen
|
|
|
|
- **Atome/Moleküle (`core:design-system`)**: Zustandlose, rein visuelle Elemente (z.B. `MsButton`, `MsCard`).
|
|
- **Plug-and-Play Organismen (`features:*` oder `core:auth`)**: Fachlich orientierte Komponenten (z.B. `AuthStatusCard`,
|
|
`PingActionGroup`). Sie MÜSSEN ein ViewModel-Interface oder ein UI-State-Objekt verwenden.
|
|
- **Templates/Screens**: Layout-orientierte Kompositionen von Organismen. Keine direkte Logik-Implementierung.
|
|
|
|
### 2. Striktes State Hoisting
|
|
|
|
- Komponenten erhalten ihren Zustand über ein ViewModel oder ein State-Objekt, das als Parameter übergeben wird.
|
|
- Sie geben Ereignisse über Lambdas zurück (z.B. `onLoginClick: () -> Unit`).
|
|
- Sie dürfen NICHT direkt innerhalb des Composables auf globale Singletons oder Koin zugreifen.
|
|
|
|
### 3. Modulare Granularität
|
|
|
|
- Features werden in kleine, testbare Einheiten zerlegt (z.B. `PingConsole`, `PingControls`).
|
|
- Komponenten befinden sich in `commonMain`, um die Multiplattform-Verfügbarkeit sicherzustellen.
|
|
|
|
## Konsequenzen
|
|
|
|
- **Positiv**: Erhöhte Stabilität, höhere Wiederverwendbarkeit über Plattformen hinweg, einfacheres Testing, schnellere
|
|
UI-Experimente.
|
|
- **Negativ**: Geringfügiger Overhead bei der Definition von Interfaces und State-Objekten für kleine Komponenten.
|
|
- **Risiko**: Over-Engineering einfacher Views. (Gegenmaßnahme: "Gesunder Menschenverstand" bei trivialen
|
|
1-Zeilen-Labels).
|
|
|
|
## Einhaltung
|
|
|
|
- Jede neue Feature-Implementierung MUSS gegen dieses ADR geprüft werden.
|
|
- Bestehende Screens SOLLTEN im Zuge der Wartung in dieses Muster refactored werden.
|