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.
This commit is contained in:
@@ -3,68 +3,68 @@ type: Reference
|
||||
status: ACTIVE
|
||||
owner: Lead Architect
|
||||
---
|
||||
# Frontend Architecture & Modularization Strategy
|
||||
# Frontend-Architektur & Modularisierungsstrategie
|
||||
|
||||
**Status:** DRAFT
|
||||
**Last Updated:** 2026-01-19
|
||||
**Context:** Migration to Clean Architecture & Feature Modules
|
||||
**Status:** ENTWURF
|
||||
**Zuletzt aktualisiert:** 2026-01-19
|
||||
**Kontext:** Migration zu Clean Architecture & Feature-Modulen
|
||||
|
||||
---
|
||||
|
||||
## 1. Overview
|
||||
The frontend architecture of **Meldestelle** is based on **Kotlin Multiplatform (KMP)** with **Compose Multiplatform** for UI. We follow a strict **Clean Architecture** approach to ensure testability, scalability, and separation of concerns.
|
||||
## 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. Module Structure
|
||||
The project is organized into the following layers:
|
||||
## 2. Modulstruktur
|
||||
Das Projekt ist in folgende Schichten unterteilt:
|
||||
|
||||
### 2.1 Core Modules (`frontend/core`)
|
||||
Reusable components that are agnostic of specific business features.
|
||||
* `core-network`: Central HTTP Client configuration (Auth, Logging, ContentNegotiation).
|
||||
* `core-sync`: Generic synchronization logic (`SyncManager`, `SyncableRepository`).
|
||||
* `core-ui`: Shared UI components and design system.
|
||||
### 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 Modules (`frontend/features`)
|
||||
Each business domain (e.g., `ping`, `auth`, `events`) resides in its own module.
|
||||
A feature module MUST follow the **Clean Architecture** package structure:
|
||||
### 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`
|
||||
* **Entities:** Pure data classes.
|
||||
* **Interfaces:** Repository interfaces, Service interfaces.
|
||||
* **Use Cases:** Business logic (optional, for complex logic).
|
||||
* **Entitäten:** Reine Datenklassen.
|
||||
* **Interfaces:** Repository-Interfaces, Service-Interfaces.
|
||||
* **Use Cases:** Geschäftslogik (optional, für komplexe Logik).
|
||||
* `at.mocode.{feature}.feature.data`
|
||||
* **Implementations:** Repository implementations, API Clients.
|
||||
* **DTOs:** Data Transfer Objects (if different from domain entities).
|
||||
* **Implementierungen:** Repository-Implementierungen, API-Clients.
|
||||
* **DTOs:** Data Transfer Objects (wenn von Domain-Entitäten abweichend).
|
||||
* `at.mocode.{feature}.feature.presentation`
|
||||
* **ViewModels:** State management.
|
||||
* **Screens:** Composable functions.
|
||||
* **ViewModels:** Zustandsverwaltung.
|
||||
* **Screens:** Composable-Funktionen.
|
||||
* `at.mocode.{feature}.feature.di`
|
||||
* **Koin Module:** Dependency injection configuration.
|
||||
* **Koin-Modul:** Konfiguration der Dependency Injection.
|
||||
|
||||
### 2.3 Shells (`frontend/shells`)
|
||||
Application entry points that wire everything together.
|
||||
* `meldestelle-portal`: The main web/desktop application.
|
||||
Anwendungs-Einstiegspunkte, die alles zusammenführen.
|
||||
* `meldestelle-portal`: Die Haupt-Web-/Desktop-Anwendung.
|
||||
|
||||
## 3. Migration Strategy (Transition Phase)
|
||||
We are currently migrating from a monolithic `clients` package structure to modular feature modules.
|
||||
## 3. Migrationsstrategie (Übergangsphase)
|
||||
Wir migrieren aktuell von einer monolithischen `clients`-Paketstruktur zu modularen Feature-Modulen.
|
||||
|
||||
**Rules for Migration:**
|
||||
1. **New Features:** Must be implemented directly in `frontend/features/{name}` using the Clean Architecture structure.
|
||||
2. **Existing Features:** Will be migrated incrementally.
|
||||
3. **Coexistence:** During the transition, legacy code in `clients/` is permitted but deprecated.
|
||||
4. **Dependency Injection:** Legacy code must use the new Koin modules if available.
|
||||
5. **No Ghost Classes:** Do not duplicate classes. If a class is moved to a feature module, delete the old one in `clients/`.
|
||||
**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. Key Decisions (ADRs)
|
||||
## 4. Wichtige Entscheidungen (ADRs)
|
||||
|
||||
### ADR-001: Sync Logic Decoupling
|
||||
* **Decision:** ViewModels must not depend directly on `SyncManager`.
|
||||
* **Reason:** To allow easier testing and to hide the complexity of the generic sync mechanism.
|
||||
* **Implementation:** Introduce a domain service interface (e.g., `PingSyncService`) that wraps the `SyncManager` call.
|
||||
### 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 Module Isolation
|
||||
* **Decision:** Feature modules should not depend on each other directly if possible.
|
||||
* **Communication:** Use shared Core modules or loose coupling via interfaces/events if cross-feature communication is needed.
|
||||
### 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.
|
||||
|
||||
---
|
||||
|
||||
**Approved by:** Lead Architect
|
||||
**Freigegeben von:** Lead Architect
|
||||
|
||||
Reference in New Issue
Block a user