Files
meldestelle/docs/ARCHITECTURE.md
T
StefanMo 034892e890 chore(MP-23): network DI client, frontend architecture guards, detekt & ktlint setup, docs, ping DI factory (#21)
* chore(MP-21): snapshot pre-refactor state (Epic 1)

* chore(MP-22): scaffold new repo structure, relocate Docker Compose, move frontend/backend modules, update Makefile; add docs mapping and env template

* MP-22 Epic 2: Erfolgreich umgesetzt und verifiziert

* MP-23 Epic 3: Gradle/Build Governance zentralisieren
2025-11-30 23:14:00 +01:00

68 lines
3.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Repository-Architektur (MP-22)
Dieses Dokument beschreibt die Zielstruktur und das Mapping vom bisherigen Stand (Ist) zur neuen Struktur (Soll). Es begleitet Epic 2 (MP-22).
Zielstruktur (Top-Level)
backend/ Gateway, Discovery (optional), Services
gateway
discovery
services
frontend/ KMP Frontend
shells Ausführbare Apps (Assembler)
features Vertical Slices (kein Feature→Feature)
core Shared Foundation (Design-System, Network, Local-DB, Auth, Domain)
docker/ Docker Compose, .env.example, Monitoring-/Core-Konfiguration
docs/ Architektur, ADRs, C4-Modelle, Guides
Ist → Soll Mapping (erste Tranche)
- Frontend
- clients/app → frontend/shells/meldestelle-portal (verschieben in Folge-Commit)
- clients/shared/common-ui → frontend/core/design-system (verschieben in Folge-Commit)
- clients/shared/navigation → frontend/core/navigation (verschieben in Folge-Commit)
- Backend
- infrastructure/gateway → backend/gateway (verschieben in Folge-Commit)
- services/* → backend/services/* (verschieben in Folge-Commit)
- Discovery (falls genutzt) → backend/discovery
- Docker
- compose.yaml → docker/docker-compose.yml (neu angelegt, Makefile angepasst)
- .env Handling → docker/.env.example (neu, als Template)
Build/Gradle
- settings.gradle.kts bleibt vorerst unverändert. Modul-Verschiebungen folgen in einem separaten Schritt mit angepassten include-Pfaden.
- Version Catalog (gradle/libs.versions.toml) bleibt die einzige Quelle der Versionswahrheit.
Richtlinien (Kurzfassung)
- Features kommunizieren ausschließlich über Routen (Navigation) und Shared-Modelle in frontend/core/domain.
- Kein manueller Authorization-Header nur der DI-verwaltete apiClient aus frontend/core/network (Koin Named Binding).
- SQLDelight als Offline-SSoT: Schema/Migrationen zentral versionieren, UI liest stets lokal und synchronisiert im Hintergrund.
DI-Policy & Architecture Guards (MP-23)
- DI-Policy (Frontend)
- HttpRequests erfolgen ausschließlich über den via Koin bereitgestellten `apiClient` (named Binding) aus `:frontend:core:network`.
- Manuelles Setzen des `Authorization`Headers ist verboten. TokenHandling wird zentral im `apiClient` konfiguriert (AuthPlugin/Interceptor).
- BasisURL wird plattformspezifisch aufgelöst:
- JVM/Desktop: Env `API_BASE_URL` (Fallback `http://localhost:8081`).
- Web/JS: `globalThis.API_BASE_URL` (z. B. per `index.html` oder Proxy), sonst `window.location.origin`, Fallback `http://localhost:8081`.
- Architecture Guards (FrontendScope)
- RootTask `archGuards` bricht den Build ab, wenn verbotene Muster gefunden werden (manuelle `Authorization`Header). Tests sind ausgenommen; Backend ist ausgenommen.
- Statische Analyse verfügbar über `detekt` und `ktlintCheck`; Aggregator `staticAnalysis` führt alles zusammen.
- Hinweise für Features
- Features importieren keine anderen Features (Kommunikation über Navigation + SharedDomainModelle). Eine explizite DetektRegel folgt.
- Netzwerkzugriffe in Features nutzen Koin über die AppShell (DIBootstrap). Für schrittweise Migration kann eine Factory den `apiClient` optional beziehen.
Nächste Schritte (MP-22 Folgetasks)
1. Physisches Verschieben der Frontend-Module gemäß Mapping und Anpassung von settings.gradle.kts.
2. Physisches Verschieben der Backend-Komponenten in backend/* inkl. evtl. Package-Pfade, sofern notwendig.
3. Ergänzung von docker-compose.services.yml und docker-compose.clients.yml mit echten Overlays.
4. Erstellen der ersten ADRs unter docs/adr (Koin, SQLDelight, Optimistic Locking, Freshness UI, Core Domain).