From 89bbd42245a55883ad4a7979e726c08f0ada6ca6 Mon Sep 17 00:00:00 2001
From: StefanMo <61204035+StefanMoCoAt@users.noreply.github.com>
Date: Sun, 30 Nov 2025 14:18:16 +0100
Subject: [PATCH] refactor/architecture-registry-masterdata (#19)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* MP-19 Refactoring: Einführung der "Registry" & "Masterdata" Trennung (Clean Architecture)

Architektur-Entscheidung: "Zwei-Welten-Modell" zur Trennung von User-Identität und Verbandsdaten.

Änderungen:
- settings.gradle.kts: Umstrukturierung der Module in 'domains', 'infrastructure', 'core'.
- Modul ':members' wurde zu ':domains:registry' (Single Source of Truth für OEPS-Daten).
- Neues Modul ':domains:registry:oeps-importer' für ZNS-Datenimports (Spring Batch Vorbereitung).
- Neues Modul ':domains:masterdata' für Regelwerke und Kataloge.
- Entfernung/Deaktivierung von Legacy-Modulen, die durch Keycloak (Docker) ersetzt wurden.

Ziel: DSGVO-konforme Trennung von "User" (Auth) und "Person" (Registry) sowie Vorbereitung für Multi-Verband-Support.

* MP-19 Refactoring: Frontend Tabula Rasa

* MP-19 Refactoring: Frontend Tabula Rasa

* refactoring:
Ein umfassender Commit wurde vorgeschlagen, der Zeittypen vereinheitlicht, Fehlercodes zentralisiert und neue Funktionen in core-utils hinzufügt. Es wurden Breaking Changes dokumentiert, insbesondere bei Datenbank-Utilities und Zeit-/Serializer-Konsolidierung. Die Commit-Nachricht folgt dem Conventional Commits-Standard und umfasst mehrere Module.

* MP-20 fix(docker/clients): include `:domains` module in web/desktop builds to fix Gradle configuration error

      Docker build der Clients schlug fehl beim Schritt `:clients:app:dependencies` mit:
      "Configuring project ':domains' without an existing directory is not allowed. The configured projectDirectory '/app/domains' does not exist..."

      Änderungen:
      - dockerfiles/clients/web-app/Dockerfile: COPY domains ./domains
      - dockerfiles/clients/desktop-app/Dockerfile: COPY domains ./domains

      Begründung:
      - `settings.gradle.kts` inkludiert `:domains`; der Ordner wurde bisher nicht in das Build-Image kopiert.
      - Dadurch konnte Gradle das Multi-Projekt im Container nicht konfigurieren.

      Hinweise:
      - Keine Laufzeitänderungen, nur Build-Fix.
      - Caching bleibt erhalten (COPY vor den Gradle-Schritten).

      Rebuild:
      - Hardcoded: `docker compose -f compose.hardcoded.yaml build web-app`
      - Env-basiert: `docker compose -f compose.yaml build web-app`

* MP-20 fix(web-app build): resolve JS compile error and add dev/prod build profile for Docker

      - clients:shared: remove legacy DI wiring to data/PingRepositoryImpl in SharedModule
      - dockerfiles/clients/*: copy `domains/` into builder to satisfy multi-project includes
      - web-app Dockerfile: add WEB_BUILD_PROFILE (dev|prod), unify dist copy via /app/web-dist
      - compose(.yaml|.hardcoded.yaml): pass WEB_BUILD_PROFILE (default dev)

      Result: JS build succeeds; flexible dev/prod bundles for faster iteration or optimized assets.

* MP-20 fix(web-app): remove vendor.js reference and harden JS bootstrap so Welcome screen renders

      Problem:
      - Web UI blieb bei „🚀 Loading Meldestelle…“ stehen, obwohl `web-app.js` (200/304) geladen wurde.
      - In DEV gab es keinen `vendor.js`-Chunk → der harte `<script src="vendor.js">`-Eintrag führte zu 404 und verhinderte den Start.

      Änderungen:
      - clients/app/src/jsMain/resources/index.html
        - Entfernt: hart codiertes `<script src="vendor.js" defer></script>`
        - Beibehalten: Single-Bundle `<script src="web-app.js" defer></script>` mit Hinweiskommentar
      - clients/app/src/jsMain/kotlin/main.kt
        - Start-Mechanik robuster gemacht: DOMContentLoaded/readyState-Check, sichtbares Fehlermeldungs-Fallback, Debug-Logs (`[WebApp] …`), Entfernen des „Loading …“-Platzhalters nach Mount
      - clients/app/build.gradle.kts
        - Sichergestellt: `binaries.executable()` und `mainOutputFileName = "web-app.js"`; keine CommonJS/`libraryTarget`-Konfiguration mehr
      - dockerfiles/clients/web-app/Dockerfile
        - Build-Profil per `WEB_BUILD_PROFILE=dev|prod` (Default: dev)
        - DEV: Single-File-Bundle (developmentExecutable) → `/app/web-dist` → Nginx
        - PROD: Distribution-Bundle (productionExecutable) → `/app/web-dist` → Nginx

      Warum:
      - DEV-Bundle emittiert i. d. R. nur `web-app.js`. Der `vendor.js`‑Request erzeugte 404 und stoppte den App-Start.
      - Robuster Bootstrap stellt sicher, dass Compose auch bei unterschiedlichen Ladezeiten zuverlässig mountet.

      Verifikation:
      - `docker compose -f compose.yaml build web-app && docker compose -f compose.yaml up -d web-app`
      - Browser: http://localhost:4000 → Welcome rendert; Network: nur `web-app.js` (200), kein `vendor.js`; Console: keine Fehler, optionale `[WebApp]`‑Logs sichtbar.

      Hinweis:
      - Für PROD (optional): `WEB_BUILD_PROFILE=prod` bauen; Chunk‑Injektion erfolgt über das Kotlin/JS‑Plugin (keine hart codierten Chunk‑Namen in HTML verwenden).

* MP-20 fixing: clients

* MP-20 fixing: clients