5.0 KiB
5.0 KiB
| type | status | owner | created | source |
|---|---|---|---|---|
| Journal | ARCHIVED | Lead Architect | 2026-03-27 | ../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.
🏗️ [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)