Remove obsolete chat logs and migrate relevant assets from docs/Neumarkt2026/ and docs/BilderSuDo/ to docs/80_Assets/. Update references and initiate consolidation of documentation.
This commit is contained in:
@@ -0,0 +1,124 @@
|
||||
---
|
||||
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)
|
||||
```
|
||||
```
|
||||
Reference in New Issue
Block a user