Master 21 - Unified Enterprise Runtime Portal - Beschreibung
Master 21 - Unified Enterprise Runtime Portal - große Erklärung
Ziel
Ein gemeinsames portal und eine runtime-zentrale für master 8 bis 20.
Warum das nach Master 20 sinnvoll ist
Master 1 bis 20 liefern Fachsysteme, Infrastruktur, Tests, CI/CD und Operations. Master 21 konkretisiert einen nächsten Reifegrad: mehr Bedienbarkeit, mehr Datenrealismus, mehr Frontend oder mehr Modernisierungstiefe.
Konkreter Ablauf
1. Portal öffnen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
2. System auswählen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
3. Demo-Daten laden - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
4. Szenario starten - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
5. Status prüfen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
6. API öffnen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
7. Report anzeigen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
Architekturgedanke
Die Module sind bewusst klein gehalten. Jedes Modul hat eine klare Aufgabe. Die Abhängigkeiten sollen nach innen zeigen; Infrastruktur bleibt austauschbar. Dadurch bleiben Refactoring, Tests und Migration möglich.
Verwendete Entwurfsmuster
• Command: Schritte sind ausführbare Aktionen.
• Pipeline: Fachliche Abläufe werden nachvollziehbar verkettet.
• Adapter: Externe Systeme werden über klare Schnittstellen angebunden.
• Facade: Das Portal oder Gateway bietet einen einfachen Einstieg.
• Strategy: Infrastruktur- und Fachvarianten bleiben austauschbar.
• Result Object: Ergebnisse werden explizit statt implizit behandelt.
Submodule und Tests
| Modul | Aufgabe | Pattern | Tests | |
|---|---|---|---|---|
scenario-catalog | Registry der im Portal ausführbaren Demo-Szenarien (Id, Titel, Ziel-Master). | Registry | ScenarioCatalogTest (2): findet registriertes Szenario, leeres Optional für unbekanntes Szenario. | |
runtime-registry | Registry bekannter Runtime-Endpunkte der anderen Master (Url, Erreichbarkeit); implementiert seit der Vertiefung den Port RuntimeCatalog, den api-console, system-status und runtime-link-adapter jetzt statt der konkreten Klasse verwenden. | Registry, Port/Adapter | RuntimeRegistryTest (2): findet registrierten Endpunkt, leeres Optional für unbekannten Master. | |
demo-data-service | Seedet und liefert reproduzierbare Demo-Daten für Portal-Szenarien. | Fixture Provider | DemoDataServiceTest (2): findet geseedete Daten, leeres Optional für unbekannten Key. | |
security-mock | Simuliert rollenbasierte Autorisierung ohne echtes Identity-Provider-Backend. | Guard | SecurityMockTest (2): autorisiert bei passender Rolle, lehnt ohne Rolle ab. | |
api-console | Übersetzt eine Portal-Konsolenabfrage in einen Aufruf gegen die Runtime-Registry. | Adapter | ApiConsoleTest (3): 200 für erreichbare Runtime, 404 für unregistrierte, 503 für unerreichbare Runtime. | |
system-status | Fasst alle registrierten Runtimes zu einem Gesamtstatus zusammen. | Composite | SystemStatusTest (2): ALL_UP wenn alle erreichbar, DEGRADED mit Namen des unerreichbaren Masters. | |
runtime-link-adapter | Baut aus einem registrierten Runtime-Endpunkt einen anklickbaren Deep-Link. | Adapter | RuntimeLinkAdapterTest (2): baut Deep-Link aus Endpunkt, lehnt unregistrierten Master ab. | |
scenario-runner | PortalSession-Aggregat (Domain) kapselt Ablauf und Rollenprüfung; ScenarioRunner (Application) orchestriert Katalog, Sitzung und Ausführung. | Szenario nachschlagen -> Sitzung starten -> Ablauf/Rolle prüfen -> ausführen | Aggregate, Application Service | PortalSessionTest (3): erlaubt Zugriff bei aktiver/berechtigter Sitzung, lehnt abgelaufene Sitzung und fehlende Rolle ab. ScenarioRunnerTest (3). |
portal-shell | PortalShell-Facade bündelt Systemstatus, Demo-Daten und Szenario-Ausführung zu einer Portal-Ansicht. | Facade | PortalShellTest (2): liefert vollständige Ansicht bei Erfolg, spiegelt abgelehntes Szenario bei fehlender Rolle. | |
runnable-smoke | Verdrahtet portal-shell, api-console und runtime-link-adapter zu einem End-to-End-Lauf (mvn -pl runnable-smoke -am package). | Command, Pipeline, Result Object | Kein eigener JUnit-Test; verifiziert STATUS=OK für alle sieben Schritte zur Laufzeit und bricht mit Fehler ab, falls einer abweicht. |
Ausbaustufe 1 (minimal lauffähig): 20 JUnit-Tests über 9 vormals leere Submodule. Ausbaustufe 2 (fachlich ausgearbeitet): scenario-runner bekam das PortalSession-Aggregat, runtime-registry einen formalen RuntimeCatalog-Port (Dependency Inversion für api-console, system-status, runtime-link-adapter) — 3 weitere Tests, macht 23 Tests insgesamt für dieses Modul. Verifiziert mit mvn test (alle grün) und dem End-to-End-Smoke-Lauf mvn -pl runnable-smoke -am package (weiterhin STATUS=OK für alle sieben Portal-Schritte).