mocode-software/meldestelle
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2dc3c4154b
meldestelle/docs/01_Architecture/Roadmap_2026_Q1.md
Stefan Mogeritsch 2dc3c4154b docs: consolidate roadmaps and update architecture documentation 
Replaced fragmented roadmaps with a single MASTER_ROADMAP for Q1 2026 as the authoritative source. Deprecated outdated roadmap files and updated Architect playbook to reflect new ownership and delegation responsibilities. Introduced architecture improvement proposals and added related documents for enhanced collaboration and knowledge sharing.
2026-01-16 10:42:34 +01:00

3.5 KiB
Raw Blame History

Roadmap Q1 2026: "Operation Tracer Bullet"

Status: Draft Owner: Lead Software Architect Ziel: Stabilisierung der Architektur und Durchstich ("Tracer Bullet") mit dem ping-service.

Phase 1: Fundament & Stabilisierung (Woche 1-2)

Das Ziel dieser Phase ist es, die Entwicklungsumgebung (Build, Docker, Dependencies) so zu stabilisieren, dass alle Entwickler (und Agenten) reibungslos arbeiten können.

1.1 Build-System & Dependencies (Architect)

  • Spring Cloud Fix: Downgrade von 2025.1.0 (Oakwood) auf 2025.0.1 (Northfields) in libs.versions.toml und platform-bom.
  • Wasm Build Fix: Analyse und Behebung der Worker / Unresolved reference Fehler im Frontend-Build. Ggf. explizite Dependency für kotlinx-browser prüfen.
  • Dependency Cleanup: Entfernen von redundanten Datenbank-Libs (Entscheidung: SQLDelight für KMP Client, Room entfernen wenn nicht genutzt; Exposed im Backend auf 1.0.0-rc-4 heben).
  • Micrometer Upgrade: Explizites Setzen von Micrometer 1.16.1 für besseren Java 25 Support.

1.2 Infrastruktur & Docker (DevOps)

  • Gateway CircuitBreaker: Behebung des ClassNotFoundException / NoSuchMethodError im Gateway (vermutlich Folge des Spring Cloud Konflikts).
  • Docker Stabilität: Sicherstellen, dass docker compose up zuverlässig alle Services (Consul, Keycloak, Postgres) startet und vernetzt.
  • Keycloak Config: Validierung der Realm-Konfiguration (meldestelle) und der Client-Scopes für den ping-service.

Phase 2: Backend Implementation "Ping" (Woche 2-3)

Implementierung des ersten vertikalen Durchstichs.

2.1 Modul-Struktur & API (Backend Dev)

  • Refactoring core-utils: Verschieben von JVM-spezifischem Code (DatabaseUtils) nach :backend:infrastructure:persistence. core-utils muss "pure KMP" sein.
  • API Definition: Erstellung von :contracts:ping-api mit KMP-kompatiblen DTOs (PingResponse).

2.2 Service Implementation (Backend Dev)

  • Ping Service: Implementierung von :backend:services:ping:ping-service mit Spring Boot 3.5.9.
  • Security: Integration von OAuth2 Resource Server (Keycloak) und Absicherung des /secure Endpoints.
  • Discovery: Registrierung bei Consul.
  • Observability: Tracing mit Zipkin und Metrics mit Prometheus aktivieren.

Phase 3: Frontend Integration (Woche 3-4)

Anbindung des Frontends an den neuen Service.

3.1 HTTP Client & Sync (Frontend Expert)

  • Ktor Client: Konfiguration des HTTP-Clients für die Kommunikation mit dem Gateway (http://localhost:8080).
  • Auth: Implementierung des OIDC-Flows im Frontend (Login via Keycloak), Speichern des Tokens.
  • Integration: Aufruf von /api/ping und /api/ping/secure und Anzeige im UI.

3.2 Offline-Sync Basis (Frontend Expert)

  • Sync-Logik: Erste Implementierung eines Sync-Mechanismus (z.B. Queue für Offline-Requests) basierend auf SQLDelight.

Phase 4: Review & Hardening (Woche 4)

4.1 Quality Assurance (QA Specialist)

  • Integrationstests: Automatisierte Tests, die den gesamten Flow (Frontend -> Gateway -> Service) prüfen.
  • Lasttests: Einfache Lasttests auf den ping-service zur Validierung der Virtual Threads.

4.2 Documentation (Curator)

  • Update Docs: Aktualisierung der Architektur-Dokumentation basierend auf den Erkenntnissen.
  • Onboarding: Sicherstellen, dass neue Entwickler das Projekt mit einem Befehl starten können.