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
This commit is contained in:
StefanMo
@@ -0,0 +1,67 @@
|
||||
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)
|
||||
- Http‑Requests erfolgen ausschließlich über den via Koin bereitgestellten `apiClient` (named Binding) aus `:frontend:core:network`.
|
||||
- Manuelles Setzen des `Authorization`‑Headers ist verboten. Token‑Handling wird zentral im `apiClient` konfiguriert (Auth‑Plugin/Interceptor).
|
||||
- Basis‑URL 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 (Frontend‑Scope)
|
||||
- Root‑Task `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 + Shared‑Domain‑Modelle). Eine explizite Detekt‑Regel folgt.
|
||||
- Netzwerkzugriffe in Features nutzen Koin über die App‑Shell (DI‑Bootstrap). 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).
|
||||
@@ -0,0 +1,13 @@
|
||||
Architecture Decision Records (ADRs)
|
||||
|
||||
Dieses Verzeichnis enthält Architekturentscheidungen in kurzer, überprüfbarer Form.
|
||||
|
||||
Namensschema: ADR-XXX-title.md mit fortlaufender Nummerierung.
|
||||
|
||||
- ADR-001 Koin als DI
|
||||
- ADR-002 SQLDelight als Offline-DB
|
||||
- ADR-003 Optimistic Locking (409) als Konfliktstrategie
|
||||
- ADR-004 Freshness UI (Ampel)
|
||||
- ADR-005 Core Domain & Feature Isolation
|
||||
|
||||
Siehe Template: ADR-000-template.md.
|
||||
@@ -0,0 +1,160 @@
|
||||
### 1\. Welche DI-Lösung? (Dependency Injection)
|
||||
|
||||
**Entscheidung:** Wir nutzen **Koin**.
|
||||
|
||||
**Begründung (ADR):**
|
||||
|
||||
* **Warum nicht Dagger/Hilt?** Hilt ist stark auf Android (Context, Lifecycles) fixiert. Dagger ist extrem komplex im Setup für Multiplatform (Kapt/KSP Setup über alle Targets).
|
||||
* **Warum Koin?** Es ist ein reines Kotlin-Framework ("Service Locator" Pattern). Es funktioniert identisch auf JVM (Desktop), JS (Web) und Android. Es benötigt keine Annotation-Processing-Magie, was die Build-Zeiten im Monorepo niedrig hält.
|
||||
|
||||
**Eintrag im Guide:**
|
||||
|
||||
```kotlin
|
||||
// GUIDELINE: Dependency Injection
|
||||
// Wir nutzen Koin. Module werden im `di` Package des Features definiert.
|
||||
|
||||
// 1. Definition (Feature Module)
|
||||
val inventoryModule = module {
|
||||
// Singletons für Services
|
||||
single<InventoryRepository> { InventoryRepositoryImpl(get(), get()) }
|
||||
|
||||
// ViewModels (Factory scope)
|
||||
viewModel { InventoryViewModel(get()) }
|
||||
}
|
||||
|
||||
// 2. Nutzung des ApiClients (Best Practice)
|
||||
// Wir injizieren IMMER den "apiClient" (mit Auth-Header), niemals den Default Client.
|
||||
val networkModule = module {
|
||||
single(named("apiClient")) { ... } // Konfiguriert in :core:network
|
||||
}
|
||||
|
||||
val myFeatureModule = module {
|
||||
single {
|
||||
// Explizites Holen des authentifizierten Clients
|
||||
MyFeatureApi(httpClient = get(named("apiClient")))
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
### 2\. Welche Offline-DB/ORM?
|
||||
|
||||
**Entscheidung:** Wir nutzen **SQLDelight**.
|
||||
|
||||
**Begründung (ADR):**
|
||||
|
||||
* **Warum nicht Room (KMP)?** Room ist für KMP noch sehr neu (Alpha/Beta Status) und bringt viel Overhead mit sich (SQLite Bundling etc.).
|
||||
* **Warum SQLDelight?**
|
||||
1. **Schema First:** Du schreibst SQL (`.sq`), und Kotlin-Code wird *generiert*. Das zwingt Entwickler dazu, über ihr Datenmodell nachzudenken, bevor sie Code schreiben.
|
||||
2. **Performance:** Es ist extrem leichtgewichtig und typ-sicher.
|
||||
3. **Migrationen:** SQLDelight hat ein exzellentes System für Schema-Migrationen (`1.sqm`, `2.sqm`), was für Desktop-Apps (die nicht einfach "neu geladen" werden können wie Webseiten) essenziell ist.
|
||||
|
||||
**Eintrag im Guide:**
|
||||
|
||||
> **DB-Guideline:**
|
||||
>
|
||||
> * Jedes Feature definiert sein Schema in `:frontend:core:local-db/src/commonMain/sqldelight/...`.
|
||||
> * Business-Logik darf niemals SQL-Strings enthalten. Nutze die generierten `Queries`-Objekte.
|
||||
> * Migrationen sind Pflicht bei Schema-Änderungen\! (Kein `DROP TABLE` in Production).
|
||||
|
||||
-----
|
||||
|
||||
### 3\. Konfliktstrategie bei Sync?
|
||||
|
||||
**Entscheidung:** **Optimistic Locking** (Server Wins).
|
||||
|
||||
**Begründung (ADR):**
|
||||
|
||||
* In einem System mit Offline-Clients ist "Last Write Wins" gefährlich (Lagerbestand wird überschrieben).
|
||||
* **Strategie:**
|
||||
1. Jedes Entity hat eine `lastUpdated` (Timestamp) Spalte.
|
||||
2. Der Client sendet beim Update die Version mit, die er *kennt*.
|
||||
3. Wenn Server-Version \> Client-Version → **HTTP 409 Conflict**.
|
||||
4. Client muss Daten neu laden (Refresh) und User fragen/informieren.
|
||||
|
||||
**Eintrag im Guide:**
|
||||
|
||||
```kotlin
|
||||
// GUIDELINE: Sync & Conflicts
|
||||
// Das Frontend führt KEIN komplexes Merging durch.
|
||||
|
||||
suspend fun updateStock(item: Item) {
|
||||
try {
|
||||
api.update(item.id, item.newStock, currentVersion = item.version)
|
||||
// Happy Path: DB Update
|
||||
} catch (e: ConflictException) { // HTTP 409
|
||||
// 1. Markiere Item in UI als "Out of Sync" (Rot)
|
||||
// 2. Trigger automatischen Refresh vom Server
|
||||
// 3. Zeige User Toast: "Daten waren veraltet. Bitte prüfen."
|
||||
repo.refreshSingleItem(item.id)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
### 4\. Error Budgets / SLIs (Stale Data Indikatoren)
|
||||
|
||||
**Entscheidung:** **Visual Freshness Indicators** (Ampel-System).
|
||||
|
||||
**Begründung (ADR):**
|
||||
|
||||
* Ein User muss wissen, ob der Lagerbestand "live" ist oder "von gestern".
|
||||
* Wir definieren keine harten Timeouts (App blockieren), sondern weiche UI-Hinweise.
|
||||
|
||||
**Eintrag im Guide:**
|
||||
|
||||
> **UI-Regel "Data Freshness":**
|
||||
> Jedes Entity in der lokalen DB hat ein Feld `lastSyncedAt`. Das UI reagiert darauf:
|
||||
>
|
||||
> * **\< 5 min:** ✅ Normalzustand (Kein Indikator).
|
||||
> * **\> 5 min:** ⚠️ Kleines gelbes "Wolke"-Icon oder ausgegrauter Text (Warnung).
|
||||
> * **\> 1 Stunde:** ❌ Roter Banner "Offline-Daten: Bestand nicht garantiert".
|
||||
> * **Aktion:** Schreibende Operationen sind bei "Rot" für kritische Bereiche (z.B. Inventur-Abschluss) gesperrt, für unkritische (z.B. Notiz anlegen) erlaubt (Queue).
|
||||
|
||||
-----
|
||||
|
||||
### 5\. API-Verträge und Kapselung der Feature-Teams
|
||||
|
||||
**Entscheidung:** **Loose Coupling via Navigation Routes & Shared Data Models (Core)**.
|
||||
|
||||
**Begründung (ADR):**
|
||||
|
||||
* Wir wollen vermeiden, dass Team A (Inventory) direkt Klassen von Team B (Checkout) importiert. Das führt zum "Monolithen-Klumpen".
|
||||
* Wir nutzen **keine** separaten Gradle-Module pro Feature-API (`:inventory-api`, `:inventory-impl`), da dies den Build-Graph unnötig aufbläht ("Gradle Overhead").
|
||||
|
||||
**Strategie:**
|
||||
|
||||
1. **Schnittstelle:** Die einzige "Public API" eines Features ist sein `EntryPoint` (Composable) und seine `Route` (String).
|
||||
2. **Datenaustausch:**
|
||||
* *Minimal:* Über URL-Parameter (IDs). `navigator.navigate("inventory/details/123")`.
|
||||
* *Objekte:* Wenn komplexe Objekte geteilt werden müssen (z.B. `UserProfile`), gehören diese in **`:frontend:core:domain`** (Shared Kernel).
|
||||
|
||||
**Eintrag im Guide:**
|
||||
|
||||
```kotlin
|
||||
// GUIDELINE: Feature Isolation
|
||||
// 1. Features importieren NIEMALS andere Features im `build.gradle.kts`.
|
||||
// 2. Kommunikation nur über Navigation (Router).
|
||||
// 3. Gemeinsam genutzte Datenobjekte (z.B. UserID, ShopID) liegen in :core:domain.
|
||||
|
||||
// FALSCH:
|
||||
import com.project.features.billing.Invoice // Abhängigkeit zu anderem Feature!
|
||||
|
||||
// RICHTIG:
|
||||
// Feature A navigiert zu Feature B via Route
|
||||
navigator.navigateTo("billing/create?orderId=123")
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
### Zusammenfassung für dein Dokument
|
||||
|
||||
Diese 5 Punkte schließen den Kreis:
|
||||
|
||||
1. **Koin** hält den Code sauber.
|
||||
2. **SQLDelight** hält die Daten sicher.
|
||||
3. **Optimistic Locking** verhindert Datenmüll.
|
||||
4. **Freshness UI** managed die Erwartungshaltung des Users.
|
||||
5. **Core Domain** verhindert Spaghetti-Code zwischen Features.
|
||||
@@ -0,0 +1,155 @@
|
||||
# 🏗 Project Architecture & Structure Guide
|
||||
|
||||
> **"Code is liability. Structure is asset."**
|
||||
> Wir bauen dieses System nicht für den schnellsten Start, sondern für die **Wartbarkeit über Jahre**, Offline-Fähigkeit und Skalierbarkeit über mehrere Teams hinweg.
|
||||
|
||||
-----
|
||||
|
||||
## 1\. Die Große Übersicht: The Monorepo Strategy
|
||||
|
||||
Wir organisieren Backend und Frontend in einem einzigen Repository (Monorepo).
|
||||
|
||||
### **Warum Monorepo? (Decision Record)**
|
||||
|
||||
* ❌ **Alternative:** Getrennte Repositories für Backend, Web-Frontend, Desktop-App.
|
||||
* **Problem dabei:** "Version Hell". Backend ändert API v1 zu v2, aber Frontend-Repo ist noch auf v1. Refactorings über die ganze Kette sind schmerzhaft.
|
||||
* ✅ **Unsere Entscheidung:** Monorepo.
|
||||
* **Atomic Commits:** Ein Pull Request enthält Backend-Änderungen UND die dazugehörige Frontend-Anpassung.
|
||||
* **Single Versioning:** Wir nutzen `gradle/libs.versions.toml` als einzige Quelle der Wahrheit für Library-Versionen (z.B. Kotlin Version) über das gesamte System hinweg.
|
||||
|
||||
-----
|
||||
|
||||
## 2\. Der "Deep Dive" in die Ordnerstruktur
|
||||
|
||||
Hier ist der detaillierte Aufriss unseres Dateisystems. Jeder Ordner hat einen spezifischen architektonischen Zweck.
|
||||
|
||||
```text
|
||||
/my-project-root
|
||||
│
|
||||
├── ⚙️ docker-compose.yml <-- Die lokale "Cloud". Startet DBs, Gateway & Services.
|
||||
├── 📄 settings.gradle.kts <-- Definiert die Module (Frontend & Backend).
|
||||
├── 📂 gradle
|
||||
│ └── libs.versions.toml <-- 🛑 STOP! Hier werden Versionen definiert. Nirgendwo sonst.
|
||||
│
|
||||
├── 📂 backend <-- ARCHITEKTUR: Hexagonal / DDD
|
||||
│ ├── 📂 gateway <-- Der "Türsteher". Routing & Auth-Check.
|
||||
│ ├── 📂 discovery <-- Das "Telefonbuch" (Consul/Service Registry).
|
||||
│ └── 📂 services <-- Die Business Logic (Microservices)
|
||||
│ ├── 📂 inventory-service
|
||||
│ │ ├── 📄 Dockerfile <-- Jedes Service ist ein isolierter Container!
|
||||
│ │ └── 📂 src/main/kotlin/.../domain <-- Reine Logik, kein Spring!
|
||||
│ └── 📂 auth-service
|
||||
│
|
||||
└── 📂 frontend <-- ARCHITEKTUR: Kotlin Multiplatform (KMP)
|
||||
│
|
||||
├── 📂 shells <-- 💡 CONCEPT: "The Assembler"
|
||||
│ │ Das sind die ausführbaren Anwendungen. Sie enthalten KEINE Logik.
|
||||
│ │ Sie "kleben" nur Features zusammen und konfigurieren DI.
|
||||
│ │
|
||||
│ ├── 📂 warehouse-app <-- Desktop-App (Windows/Linux) für Lageristen
|
||||
│ │ └── build.gradle.kts (bindet :features:inventory ein)
|
||||
│ └── 📂 admin-portal <-- Web-App (JS/Wasm) für Management
|
||||
│ └── build.gradle.kts (bindet alle Features ein)
|
||||
│
|
||||
├── 📂 features <-- 💡 CONCEPT: "Vertical Slices" (Micro-Frontends)
|
||||
│ │ Hier passiert die Arbeit. Ein Feature gehört einem Team.
|
||||
│ │
|
||||
│ ├── 📂 inventory-feature
|
||||
│ │ ├── 📂 src/commonMain
|
||||
│ │ │ ├── 📂 api <-- Public Interface (Der Vertrag nach außen)
|
||||
│ │ │ ├── 📂 ui <-- Screens & Components (Internal)
|
||||
│ │ │ └── 📂 data <-- Repository & SSoT (Internal)
|
||||
│ │ └── build.gradle.kts
|
||||
│ └── 📂 auth-feature
|
||||
│
|
||||
└── 📂 core <-- 💡 CONCEPT: "Shared Foundation"
|
||||
│ Code, der sich selten ändert, aber überall genutzt wird.
|
||||
│
|
||||
├── 📂 design-system <-- UI-Baukasten (Farben, Typo, Buttons)
|
||||
├── 📂 network <-- HTTP Clients & Auth-Interceptor
|
||||
├── 📂 local-db <-- SQLDelight Schemas (Die Offline-Wahrheit)
|
||||
└── 📂 auth <-- OAuth2 Logik (Browser Bridge für Desktop)
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
## 3\. Architectural Decision Records (ADRs)
|
||||
|
||||
Warum haben wir das so gebaut? Hier sind die Antworten auf die "Warum nicht X?" Fragen.
|
||||
|
||||
### ADR 001: Kotlin Multiplatform vs. Electron / Web-Wrapper
|
||||
|
||||
* **Kontext:** Wir brauchen eine Web-App UND eine Desktop-App.
|
||||
* **Entscheidung:** Wir nutzen **Kotlin Multiplatform (Compose)**.
|
||||
* **Begründung:**
|
||||
* *Performance:* Electron braucht pro App \~200MB RAM (Chromium Instanz). Unsere Desktop-Apps (Lager, Kasse) laufen auf schwacher Hardware. JVM/Native ist effizienter.
|
||||
* *Type Safety:* Wir teilen Business-Logik (Validation, SSoT) zwischen Web und Desktop. Mit JS/Electron müssten wir Logik duplizieren oder transpilen.
|
||||
* *Offline:* Echte SQL-Datenbank (SQLite) Integration ist in nativem Code robuster als im Browser-Storage.
|
||||
|
||||
### ADR 002: Multiple App Shells vs. One "Super-App"
|
||||
|
||||
* **Kontext:** Wir haben Lagerarbeiter, Kassierer und Manager.
|
||||
* **Entscheidung:** Wir bauen **pro Rolle eine eigene "Shell"** (Executable).
|
||||
* **Begründung:**
|
||||
* *Security (Web):* "Tree Shaking". Wenn der Code für "Admin-User-Löschen" gar nicht erst in der `warehouse-app.js` enthalten ist, kann er auch nicht gehackt werden.
|
||||
* *Focus (Desktop):* Die Lager-App startet schneller und hat weniger Bugs, weil sie den Code für das Rechnungswesen gar nicht lädt.
|
||||
* *Flexibilität:* Wir können Features wiederverwenden. Das Feature `auth-feature` ist in ALLEN Apps, `inventory-feature` nur in zweien.
|
||||
|
||||
### ADR 003: Single Source of Truth (SSoT) via Database
|
||||
|
||||
* **Kontext:** Desktop-Apps werden in Hallen mit schlechtem WLAN genutzt.
|
||||
* **Entscheidung:** **Database First Architecture**.
|
||||
* **Begründung:**
|
||||
* Klassisch (`UI -> API -> UI`) führt zu weißen Screens und Ladekreisen bei Netzschwankungen.
|
||||
* Wir nutzen `UI -> Local DB <- Sync -> API`.
|
||||
* Das UI zeigt **immer** Daten an (auch wenn sie 10 Minuten alt sind). Der User kann arbeiten. Sync passiert transparent im Hintergrund.
|
||||
|
||||
### ADR 004: Docker für alles (außer Desktop Runtime)
|
||||
|
||||
* **Kontext:** "Bei mir läuft's aber..." Probleme.
|
||||
* **Entscheidung:** Das gesamte Backend + Web-Frontend Build-Pipeline läuft in Docker.
|
||||
* **Begründung:**
|
||||
* Die `docker-compose.yml` ist die Wahrheit.
|
||||
* Für die Desktop-Entwicklung nutzen wir Gradle lokal, aber der Server, gegen den entwickelt wird, läuft im Container. Das garantiert Identität zwischen Dev und Prod.
|
||||
|
||||
-----
|
||||
|
||||
## 4\. Guidelines: Wo gehört mein Code hin?
|
||||
|
||||
Wenn du neuen Code schreibst, stelle dir diese Fragen:
|
||||
|
||||
### Q1: Ist es Business Logik (z.B. "Preis berechnen")?
|
||||
|
||||
* ➡️ Gehört in **`/backend/services/.../domain`** (Server-Side Validierung ist Pflicht).
|
||||
* ➡️ UND optional in **`/frontend/features/.../domain`** (für schnelle UI-Feedback, aber Server hat das letzte Wort).
|
||||
|
||||
### Q2: Ist es ein UI-Element (z.B. "Runder Button")?
|
||||
|
||||
* ➡️ Gehört in **`/frontend/core/design-system`**.
|
||||
* 🛑 *Stop\!* Baue keine Custom Buttons in deinem Feature-Ordner. Nutze das Design System. Wenn etwas fehlt, erweitere das Design System.
|
||||
|
||||
### Q3: Ich brauche Daten von einem anderen Service.
|
||||
|
||||
* **Szenario:** Im "Checkout" (Kasse) brauche ich den Produktnamen aus dem "Inventory".
|
||||
* ❌ **Falsch:** `CheckoutService` ruft `InventoryService` Datenbank direkt ab.
|
||||
* ✅ **Richtig (Backend):** `CheckoutService` ruft `InventoryService` via REST/gRPC über das Gateway.
|
||||
* ✅ **Richtig (Frontend):** Das `Checkout-Feature` kennt das `Inventory-Feature` nicht. Es bekommt nur eine `productId`. Wenn es Details anzeigen muss, nutzt es entweder ein eigenes minimales Datenmodell oder fragt das Backend.
|
||||
|
||||
### Q4: Auth Token Handling
|
||||
|
||||
* ❌ **Niemals:** `httpClient.header("Authorization", token)` manuell aufrufen.
|
||||
* ✅ **Immer:** Nutze den konfigurierten Client aus dem DI-Container: `get(named("apiClient"))`. Die Architektur kümmert sich um Refresh und Injection.
|
||||
|
||||
-----
|
||||
|
||||
## 5\. Das "Mental Model" für Entwickler
|
||||
|
||||
Stell dir unsere App wie einen **Lego-Baukasten** vor.
|
||||
|
||||
1. **Core (Platte):** Das Fundament (Auth, Network, Design). Muss immer da sein.
|
||||
2. **Features (Steine):** Bunte Bausteine (Inventory, Cart, Profile). Sie berühren sich seitlich nicht (keine direkten Abhängigkeiten).
|
||||
3. **Shells (Modelle):** Das fertige Haus.
|
||||
* Haus A (Admin Portal) nutzt alle Steine.
|
||||
* Haus B (Lager App) nutzt nur die grünen Steine (Inventory).
|
||||
|
||||
Dein Job als Entwickler ist es meistens, **einen neuen Stein (Feature)** zu bauen oder einen bestehenden zu verbessern. Du musst dich selten um das Fundament oder das fertige Haus kümmern.
|
||||
Reference in New Issue
Block a user