125 lines
5.0 KiB
Markdown
125 lines
5.0 KiB
Markdown
---
|
||
type: Journal
|
||
status: ARCHIVED
|
||
owner: Lead Architect
|
||
created: 2026-03-27
|
||
source: ../temp/Caht-Verlauf_2026-03-27.md
|
||
---
|
||
|
||
# Chat-Verlauf — 27. März 2026
|
||
|
||
Hinweis: Inhalt aus `docs/temp/Caht-Verlauf_2026-03-27.md` übernommen. Original belassen, bis die vollständige Migration abgeschlossen ist.
|
||
|
||
```text
|
||
🏗️ [Lead Architect]
|
||
Guten Morgen!
|
||
Datum: 27. März 2026
|
||
|
||
In den letzten Tagen haben wir am Frontend gebastelt.
|
||
Jetzt habe ich Angst, dass wir unseren Fokus verlieren.
|
||
|
||
Das Frontend und dessen Entwürfe sollten uns helfen die einzelnen Workflows praxisnah abzugrenzen. Daraus ergibt sich
|
||
eine Domäne/Boundet-Context und dieses Wollen wir als eigenständigen Service entwickeln.
|
||
Das Ping-Service sollte für uns quasi als Vorlage dienen, also komplett von der echten fachlichen Implementierung
|
||
isoliert.
|
||
Mittlerweile vermischen wir alles miteinander und das gefällt mir nicht.
|
||
|
||
Ich will für die ganzen technischen Implementierungen mit dessen Monitorings und Metriken ein eigenes isoliertes
|
||
Frontend in dem dann auch das Ping-Service enthalten sein soll.
|
||
|
||
Aber, dadurch dass wir nicht mehr viel Zeit haben bis zum ersten Einsatz in Neumarkt, will ich die wichtigsten
|
||
Grundlegende Funktionen bereits einsatzbereit haben, ohne dabei durch schlampiges husch pfusch eine saubere
|
||
Weiterentwicklung verbauen.
|
||
|
||
Verstehst du meine bedenken?
|
||
|
||
Ich will mit dir jetzt einen Fahrplan durchdiskutieren, was wir jetzt wie genau entwickeln wollen. Bist du damit
|
||
einverstanden?
|
||
|
||
---
|
||
|
||
🏗️ [Lead Architect]
|
||
|
||
### Kurzantwort
|
||
|
||
Ja, ich verstehe deine Bedenken. Wir trennen konsequent die fachlichen Kontexte vom technischen Monitoring, kapseln das
|
||
`Ping-Service` als reine technische Schablone, und liefern bis Neumarkt ein minimal tragfähiges Set an Kernfunktionen
|
||
ohne künftige Weiterentwicklung zu verbauen. Unten ist ein konkreter, umsetzbarer Fahrplan mit klaren Leitplanken,
|
||
Architektur-Skizze, Modulschnitt und Sprint-Plan.
|
||
|
||
---
|
||
|
||
### Leitplanken (nicht verhandelbar)
|
||
|
||
- Bounded Contexts pro Domäne: kein Mischen von fachlichen Flows mit technischen Utilities.
|
||
- Zwei getrennte UIs:
|
||
- Fach-UI: produktive Workflows (Meldungen etc.).
|
||
- TechOps-UI: Betrieb, Metriken, Logs, `Ping-Service` (Referenz/Schablone), Admin-Tools.
|
||
- `Ping-Service` bleibt fachlich neutral: keine Domänen-Referenzen, dient nur als Vorlage für technische Patterns (
|
||
Transport, Observability, Resilience, CI/CD).
|
||
- Offline-First bleibt Prinzip: Sync-Schicht ist eigenständig, nicht in Screens verwoben.
|
||
- „Saubere Weiterentwicklung“ absichern durch: stabile Contracts (`api`-Module), Consumer-Driven-Contracts,
|
||
Telemetrie-Standards, Migrationspfade.
|
||
|
||
---
|
||
|
||
### Zielbild: Kontext-/Service-Architektur
|
||
|
||
- Fachliche Kontexte (Beispiele – bitte bei Bedarf präzisieren):
|
||
- `Meldung-Erfassung` (Form, Validierung, Lokalspeicher, Drafts)
|
||
- `Meldung-Verwaltung` (Liste, Details, Statuswechsel)
|
||
- `Sync` (Offline-Queue, Konfliktlösung, Retry)
|
||
- `Auth/Identity` (Rollen/Permissions, lokale Session)
|
||
- Technischer Kontext:
|
||
- `TechOps` (Monitoring-UI, Admin-Funktionen)
|
||
- `Ping-Service` (Health, Latenz, Transportwege, Resilience-Demo)
|
||
- Context Map: klare Schnittstellen zwischen `Fach` ↔ `Sync` ↔ `Backend-APIs` sowie `TechOps` isoliert daneben.
|
||
|
||
---
|
||
|
||
### Frontend-Aufteilung (KMP/Compose, Beispiele passend zum Repo)
|
||
|
||
- `frontend/shells/meldestelle-desktop` → Fach-UI Shell
|
||
- `frontend/shells/techops-desktop` → NEU: TechOps-UI Shell (enthält `Ping`-Feature, Metriken/Logs)
|
||
- `frontend/features/*` → Feature-Module pro Kontext:
|
||
- `features/meldung-erfassung`
|
||
- `features/meldung-verwaltung`
|
||
- `features/auth`
|
||
- `features/sync`
|
||
- `features/ping-feature` (nur in `techops-desktop` eingebunden)
|
||
- `frontend/core/*` → Querschnitt (Design-System, Navigation, State, Telemetrie-SDK, Storage-Abstraktion)
|
||
- Strikte Regel: `features/ping-feature` darf kein fachliches Modul importieren. Fach-Features dürfen `ping` nicht
|
||
importieren.
|
||
|
||
---
|
||
|
||
### Backend-Aufteilung (Kotlin/Spring Boot als Annahme)
|
||
|
||
- `services/ping` → reine Technik (Health, echo, stream), OpenAPI, OTel, RateLimit, Chaos toggelbar.
|
||
- `services/meldung` → Domäne (Erfassung, Verwaltung, Validierung), eigene DB-Schemata.
|
||
- `services/auth` → Rollen/Claims, Tokens.
|
||
- `platform/observability` → Zentral: OTel Collector, Metrics, Tracing, Log-Pipeline.
|
||
|
||
---
|
||
|
||
### MVP für Neumarkt (einsatzbereit, aber erweiterbar)
|
||
|
||
- Fach-UI
|
||
- `Meldung erfassen`: Basisformular, Pflichtfelder, lokale Drafts, Validierung.
|
||
- `Meldung verwalten`: Liste, Detailansicht, einfacher Statuswechsel.
|
||
- `Sync`: Hintergrund-Sync mit Retry, Konflikt-Hinweis-UI (einfacher Merge/Last-Write-Wins als Start, später
|
||
verfeinern).
|
||
- `Auth`: Lokale Anmeldung (konfigurierbar), Rollen-Gating auf kritische Aktionen.
|
||
- TechOps-UI
|
||
- `Ping`-Dashboard: Latenz/Verfügbarkeit, einfache Last- und Retry-Demos.
|
||
- `Metrics`: Service-Health, Build-Infos, Versionen, simple Logs-View.
|
||
- Nicht-Ziele für MVP: komplexe Berichte, granularer Rechtemanager, komplexe Konfliktlösung.
|
||
|
||
---
|
||
|
||
### Roadmap bis Neumarkt (Beispiel: 3 Sprints à 2 Wochen)
|
||
```
|
||
… (vollständiger Verlauf aus der Quelle)
|
||
```
|
||
```
|