refactor(ping-feature): remove deprecated PingFeature files and legacy implementations
Deleted obsolete files and models from the `ping-feature` module, including redundant enums, the old `PingApiClient`, and legacy view models. Simplified the module by consolidating its implementation with the new Koin-based DI and shared client architecture. Cleaned up unused code and improved module maintainability.
This commit is contained in:
@@ -0,0 +1,65 @@
|
||||
# Frontend Architecture & Modularization Strategy
|
||||
|
||||
**Status:** DRAFT
|
||||
**Last Updated:** 2026-01-19
|
||||
**Context:** Migration to Clean Architecture & Feature Modules
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
|
||||
## 2. Module Structure
|
||||
The project is organized into the following layers:
|
||||
|
||||
### 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.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:
|
||||
|
||||
* `at.mocode.{feature}.feature.domain`
|
||||
* **Entities:** Pure data classes.
|
||||
* **Interfaces:** Repository interfaces, Service interfaces.
|
||||
* **Use Cases:** Business logic (optional, for complex logic).
|
||||
* `at.mocode.{feature}.feature.data`
|
||||
* **Implementations:** Repository implementations, API Clients.
|
||||
* **DTOs:** Data Transfer Objects (if different from domain entities).
|
||||
* `at.mocode.{feature}.feature.presentation`
|
||||
* **ViewModels:** State management.
|
||||
* **Screens:** Composable functions.
|
||||
* `at.mocode.{feature}.feature.di`
|
||||
* **Koin Module:** Dependency injection configuration.
|
||||
|
||||
### 2.3 Shells (`frontend/shells`)
|
||||
Application entry points that wire everything together.
|
||||
* `meldestelle-portal`: The main web/desktop application.
|
||||
|
||||
## 3. Migration Strategy (Transition Phase)
|
||||
We are currently migrating from a monolithic `clients` package structure to modular feature modules.
|
||||
|
||||
**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/`.
|
||||
|
||||
## 4. Key Decisions (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-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.
|
||||
|
||||
---
|
||||
|
||||
**Approved by:** Lead Architect
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: Report
|
||||
status: FINAL
|
||||
owner: Frontend Expert
|
||||
date: 2026-01-19
|
||||
tags: [frontend, refactoring, clean-architecture, ping-feature]
|
||||
---
|
||||
|
||||
# 🚩 Statusbericht: Frontend Refactoring (19. Jänner 2026)
|
||||
|
||||
**Status:** ✅ **Erfolgreich abgeschlossen**
|
||||
|
||||
Wir haben die vom Lead Architect kritisierte Fragmentierung im Frontend behoben und das Ping-Feature auf eine saubere **Clean Architecture** migriert.
|
||||
|
||||
### 🎯 Erreichte Ziele (DoD)
|
||||
|
||||
1. **ViewModel-Fragmentierung behoben:**
|
||||
* Die zwei parallelen `PingViewModel`-Implementierungen wurden konsolidiert.
|
||||
* Das neue ViewModel (`at.mocode.ping.feature.presentation.PingViewModel`) vereint API-Calls und Sync-Logik.
|
||||
* Das alte Package `at.mocode.clients.pingfeature` wurde **vollständig entfernt**.
|
||||
|
||||
2. **Clean Architecture Struktur:**
|
||||
* Das Ping-Feature folgt nun strikt der neuen Struktur:
|
||||
* `data`: `PingApiKoinClient`, `PingEventRepositoryImpl`
|
||||
* `domain`: `PingSyncService` (neu eingeführt zur Entkopplung)
|
||||
* `presentation`: `PingViewModel`, `PingScreen`
|
||||
* `di`: `pingFeatureModule`
|
||||
|
||||
3. **UI Integration:**
|
||||
* Der `PingScreen` wurde aktualisiert und enthält nun einen **"Sync Now"-Button** sowie eine Statusanzeige für den Sync-Vorgang.
|
||||
|
||||
4. **Test-Stabilität:**
|
||||
* Die Unit-Tests (`PingViewModelTest`) wurden massiv verbessert.
|
||||
* Wir nutzen nun **manuelle Fakes** (`FakePingSyncService`, `TestPingApiClient`) statt Mocking-Frameworks, um 100% JS-Kompatibilität zu gewährleisten.
|
||||
* Race-Conditions in den Tests wurden durch korrekte Nutzung von `StandardTestDispatcher` und `advanceUntilIdle()` behoben.
|
||||
* Namenskonflikte bei `Clock` wurden durch explizite Imports (`kotlin.time.Clock`) gelöst.
|
||||
|
||||
### 🛠️ Technische Details
|
||||
|
||||
* **Dependency Injection:** Das `pingFeatureModule` stellt alle Komponenten bereit und nutzt den zentralen `apiClient` aus dem Core.
|
||||
* **Sync-Abstraktion:** Ein `PingSyncService` Interface wurde eingeführt, um das ViewModel vom generischen `SyncManager` zu entkoppeln. Dies erleichtert das Testen und zukünftige Erweiterungen.
|
||||
* **Build:** Der Build ist **grün** (inkl. JS/Webpack und JVM Tests).
|
||||
|
||||
### 📝 Empfehlung für Folgemaßnahmen
|
||||
|
||||
* **Members & Auth Feature:** Diese sollten bei der nächsten Bearbeitung ebenfalls auf die neue Struktur (`at.mocode.{feature}.feature.*`) migriert werden.
|
||||
* **Sync Up:** Aktuell testen wir nur "Sync Down" (Server -> Client). Für einen vollständigen Offline-Test sollte eine "Create Ping"-Funktion (Sync Up) ergänzt werden, sobald das Backend dies unterstützt.
|
||||
|
||||
---
|
||||
|
||||
**Fazit:** Das Ping-Feature ist nun die **"Goldene Vorlage"** für alle kommenden Features.
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
type: Report
|
||||
status: APPROVED
|
||||
owner: Lead Architect
|
||||
date: 2026-01-19
|
||||
tags: [architecture, review, frontend, ping-feature]
|
||||
---
|
||||
|
||||
# 🏗️ Lead Architect Review: Frontend Refactoring
|
||||
|
||||
**Datum:** 19. Jänner 2026
|
||||
**Status:** ✅ **APPROVED**
|
||||
**Referenz:** `docs/90_Reports/2026-01-19_Frontend_Refactoring_Status.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. Bewertung der Umsetzung
|
||||
|
||||
Ich habe die Änderungen des Frontend Experts geprüft und bin mit dem Ergebnis **sehr zufrieden**. Die kritisierten Punkte aus dem Handover vom 17.01. wurden präzise und vollständig adressiert.
|
||||
|
||||
### ✅ Architektur-Konsistenz
|
||||
* **Clean Architecture:** Die Struktur unter `at.mocode.ping.feature` ist vorbildlich (`data`, `domain`, `presentation`, `di`).
|
||||
* **Single Source of Truth:** Das Legacy-Package `at.mocode.clients.pingfeature` wurde restlos entfernt. Es gibt keine "Ghost-Klassen" mehr.
|
||||
* **Entkopplung:** Die Einführung des `PingSyncService` Interfaces im Domain-Layer ist ein exzellenter Schachzug, um die UI vom generischen `SyncManager` zu isolieren.
|
||||
|
||||
### ✅ Integration (DoD erfüllt)
|
||||
* **UI Wiring:** Die `MainApp.kt` importiert nun korrekt `at.mocode.ping.feature.presentation.PingScreen` und `PingViewModel`.
|
||||
* **User Feedback:** Der `PingScreen` enthält nun den geforderten "Sync Now"-Button und zeigt das Ergebnis (`lastSyncResult`) an. Damit ist der Sync-Prozess für den User transparent.
|
||||
|
||||
### ✅ Code-Qualität
|
||||
* **Koin Modul:** Das `pingFeatureModule` ist sauber definiert und nutzt `named("apiClient")` korrekt für den authentifizierten Zugriff.
|
||||
* **JS-Kompatibilität:** Der explizite Einsatz von `kotlin.time.Clock` vermeidet bekannte Probleme im Multiplatform-Umfeld.
|
||||
|
||||
---
|
||||
|
||||
## 2. Arbeitsaufträge & Nächste Schritte
|
||||
|
||||
Da der "Trace Bullet" nun erfolgreich durchschlagen hat (Backend + Frontend + Sync + Auth), können wir die Entwicklung skalieren.
|
||||
|
||||
### A. @Frontend Expert (Priorität: MITTEL)
|
||||
**Aufgabe:** Migration weiterer Features.
|
||||
1. Wende das "Ping-Pattern" (Clean Arch) auf das `auth-feature` an.
|
||||
2. Stelle sicher, dass auch dort ViewModels und Repositories sauber getrennt sind.
|
||||
|
||||
### B. @Backend Developer (Priorität: HOCH)
|
||||
**Aufgabe:** Vorbereitung der Fachdomänen.
|
||||
1. Beginne mit der Modellierung der **Veranstaltungen (Events)** Domain.
|
||||
2. Erstelle die API-Contracts (`contracts` Modul) basierend auf den Anforderungen.
|
||||
|
||||
### C. @Infrastructure & DevOps (Priorität: NIEDRIG)
|
||||
**Aufgabe:** Monitoring-Check.
|
||||
1. Prüfe in den nächsten Tagen die Logs auf eventuelle Sync-Fehler, die durch die neue Frontend-Implementierung ausgelöst werden könnten.
|
||||
|
||||
---
|
||||
|
||||
## 3. Fazit
|
||||
|
||||
Der Architektur-Knoten ist gelöst. Das Projekt befindet sich nun auf einem stabilen Fundament für die weitere Skalierung.
|
||||
|
||||
**Lead Architect**
|
||||
*End of Review*
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: Journal
|
||||
date: 2026-01-19
|
||||
author: Lead Architect
|
||||
participants:
|
||||
- Frontend Expert
|
||||
- Infrastructure & DevOps
|
||||
- QA Specialist
|
||||
status: COMPLETED
|
||||
---
|
||||
|
||||
# Session Log: 19. Jänner 2026
|
||||
|
||||
## Zielsetzung
|
||||
Abschluss des "Trace Bullet" (Ping Feature) durch Abarbeitung der offenen Punkte aus dem Handover vom 17.01. und Bereinigung der Frontend-Struktur.
|
||||
|
||||
## Durchgeführte Arbeiten
|
||||
|
||||
### 1. Frontend Refactoring & Cleanup
|
||||
* **Migration:** Tests aus `at.mocode.clients.pingfeature` wurden in die Clean Architecture Struktur (`at.mocode.ping.feature.data` und `presentation`) migriert.
|
||||
* **Cleanup:** Das alte Package `at.mocode.clients.pingfeature` wurde vollständig entfernt (inkl. Tests).
|
||||
* **Integration Test:** Ein neuer `PingSyncIntegrationTest` wurde erstellt, der den Datenfluss vom API-Client bis zum Repository verifiziert.
|
||||
|
||||
### 2. Infrastructure & Observability
|
||||
* **Tracing Fix:** Der `ping-service` hatte die Tracing-Dependencies (`monitoring-client`) nicht eingebunden. Dies wurde in der `build.gradle.kts` korrigiert. Nun sollten Traces lückenlos in Zipkin erscheinen.
|
||||
|
||||
### 3. Build & Contracts
|
||||
* **API Visibility:** `contracts:ping-api` exportiert nun `core-domain` via `api` statt `implementation`. Dies behebt die Compiler-Warnung `Cannot access 'Syncable'`.
|
||||
|
||||
### 4. Dokumentation
|
||||
* **Architecture:** Neue Datei `docs/01_Architecture/02_Frontend_Architecture.md` erstellt, die die Modularisierungsstrategie und Clean Architecture Vorgaben festhält.
|
||||
|
||||
## Ergebnisse
|
||||
* Der Build ist **GRÜN**.
|
||||
* Die Architektur ist konsistent (keine Legacy-Pakete mehr im Ping-Feature).
|
||||
* Observability ist im Backend sichergestellt.
|
||||
|
||||
## Nächste Schritte (Ausblick)
|
||||
* Beginn der Arbeit an den Fachdomänen (Veranstaltungen/Events).
|
||||
* Migration des `auth-feature` auf die neue Architektur bei nächster Gelegenheit.
|
||||
Reference in New Issue
Block a user