mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
3949ab21db
meldestelle/docs/90_Reports/2026-04-02_Architect_Report.md
Stefan Mogeritsch cdadcf4611 docs(reports): add comprehensive status and recommendation reports for key roles 
- Created and saved detailed reports for Frontend, Backend, UI/UX, Architecture, DevOps, QA, Rulebook, and Curation in `docs/90_Reports/`.
- Included prioritized action items, challenges, and next steps across disciplines.
- Addressed documentation gaps and organized steps for improving workflow consistency and validation across the stack.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
2026-04-02 11:15:38 +02:00

2.4 KiB
Raw Blame History

🏗️ [Lead Architect] Report - 2. April 2026

1. Aktueller Status

Das Projekt hat durch die "Event-First"-Philosophie (Initialisierung einer spezifischen Datenbank pro Veranstaltung) und die fokussierte Compose-Desktop-Entwicklung (V2-Screens) eine deutliche Richtung eingenommen. Die Architekturentscheidung (ADR-0020) bezüglich LAN-Isolation und Mandantenfähigkeit (Tenant-per-Event) beginnt sich im Code (lokaler State, Event-bezogene Stores) niederzuschlagen, muss aber zwingend im Backend nachgezogen werden.

2. Empfehlungen & Prioritäten

🔴 P1: Mandantenfähigkeit (Tenant Isolation) im Backend verankern

  • Warum: Das Frontend plant für jedes Event eine "eigene Datenbank". Das Backend läuft derzeit noch als klassischer Monolith ohne harte Isolation der Veranstaltungsdaten (Nennungen, Prüfungen, Starterlisten). Wenn wir dies jetzt nicht architektonisch sauber im Backend (z.B. über Schema-per-Tenant oder Tenant-IDs in allen Tabellen) lösen, bauen wir enorme technische Schulden auf.
  • Aktion: Definition der Tenant-Resolution-Strategie für Ktor/Spring Boot (wie erkennt das Backend, auf welche Event-Datenbank eine Anfrage zielt?). Umsetzung im Datenzugriff-Layer.

🔴 P1: State-Management-Architektur für Compose (MVI/MVVM)

  • Warum: Der aktuelle Frontend-Code mischt UI-Deklaration und Business-Logik (StoreV2 Aufrufe direkt in den onSaved-Callbacks, viel lokaler remember-State). Bei steigender Komplexität (z.B. Nennungssystem) wird dies unwartbar.
  • Aktion: Verbindliche Festlegung auf ein Architekturmuster für das KMP/Compose Frontend (z.B. striktes MVVM mit UDF - Unidirectional Data Flow). Auslagern des Status in ViewModels und Definition klarer Intent/State Klassen für die V2-Screens.

🟠 P2: Synchronisations-Protokoll (Offline-First/LAN)

  • Warum: Die Meldestelle muss offline auf Turnieren funktionieren.
  • Aktion: Start der Konzeptionsphase für das Daten-Synchronisations-Protokoll zwischen der Master-Datenbank (Backend) und den lokalen Client-Datenbanken (Desktop). Entscheidung zwischen Event-Sourcing, CRDTs oder simplen Timestamp-basierten Sync-Ansätzen.

🟡 P3: Master-Roadmap Update

  • Warum: Die jüngsten Entwicklungen haben die Prioritäten verschoben.
  • Aktion: Aktualisierung der MASTER_ROADMAP.md in docs/01_Architecture/, um den Fokus auf die Desktop-App, die Tenant-Isolation und die anstehenden Offline-Sync-Meilensteine widerzuspiegeln.