Master 23 - Frontend & Backoffice Portal Master - Beschreibung
Master 23 - Frontend & Backoffice Portal Master - große Erklärung
Ziel
Benutzeroberflächen, backoffice-ansichten, customer portal und api-verbrauch.
Warum das nach Master 20 sinnvoll ist
Master 1 bis 20 liefern Fachsysteme, Infrastruktur, Tests, CI/CD und Operations. Master 23 konkretisiert einen nächsten Reifegrad: mehr Bedienbarkeit, mehr Datenrealismus, mehr Frontend oder mehr Modernisierungstiefe.
Konkreter Ablauf
1. Login Mock - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
2. Dashboard anzeigen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
3. Fachfall suchen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
4. Formular bearbeiten - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
5. API aufrufen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
6. Fehler anzeigen - dieser Schritt zeigt, wie Fachlichkeit und Technik zusammenlaufen.
7. Aktion abschließen - 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 | |
|---|---|---|---|---|
state-model | Hält den aktuell sichtbaren Bildschirm des Frontends zentral vor. | State | StateStoreTest (2): startet im Initial-Bildschirm, wechselt auf angeforderten Bildschirm. | |
form-validation | Prüft Pflichtfelder, bevor ein Formular an das Backend geht. | Validator | FormValidatorTest (3): akzeptiert vollständiges Formular, meldet fehlendes Pflichtfeld, ignoriert optionale Felder. | |
api-client | Übersetzt einen Frontend-Aufruf in eine simulierte Backend-Antwort. | Adapter | ApiClientTest (2): 200 für registrierte Route, 404 für unregistrierte Route. | |
error-ui | Übersetzt Backend-Statuscodes in eine anzeigbare Fehlermeldung. | Translator | ErrorPresenterTest (3): Meldung für 404, 403 und unbekannten Statuscode. | |
mock-auth-ui | Simuliert einen Login-Bildschirm ohne echtes Identity-Provider-Backend. | Guard | MockAuthGateTest (3): meldet bekannten Demo-User an, lehnt falsches Passwort und unbekannten User ab. | |
customer-portal | CustomerPortal-Facade bündelt Formularprüfung und Backend-Aufruf für den Kunden-Self-Service. | Facade | CustomerPortalTest (2): reicht gültigen Antrag ein, lehnt Antrag mit fehlendem Pflichtfeld ab. | |
backoffice-portal | BackofficePortal-Facade bündelt Login und Fallabfrage. Neu: Case-Aggregat (Domain) mit Workflow NEW -> IN_REVIEW -> APPROVED/REJECTED -> CLOSED; CaseWorkflowService (Application) entscheidet anhand der Backend-Antwort über den BackendGateway-Port. | Login prüfen -> Fall öffnen -> Review starten -> über Port entscheiden -> abschließen | Facade, Aggregate (Process Manager), Port/Adapter, Application Service | BackofficePortalTest (2). CaseTest (4): durchläuft den Workflow korrekt, lehnt Genehmigung ohne Review und Abschluss aus Review ab, erlaubt Abschluss eines abgelehnten Falls. CaseWorkflowServiceTest (2): genehmigt und schließt bei bestätigtem Fall, lehnt ab und schließt bei unbekanntem Fall. |
admin-console | Nur ADMIN darf über AdminConsole den globalen Systemzustand ändern. | Guard, Command | AdminConsoleTest (2): erlaubt Admin das Umschalten eines Feature-Flags, lehnt Nicht-Admin ab. | |
frontend-shell | FrontendShell-Facade routet zwischen Login, Fachfall-Ansicht und Fehleranzeige. | Facade | FrontendShellTest (3): zeigt Fallansicht bei Erfolg, Fehlerbildschirm bei fehlgeschlagenem Login und bei unbekanntem Fall. | |
runnable-smoke | Verdrahtet frontend-shell, customer-portal und admin-console 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): 22 JUnit-Tests über 9 vormals leere Submodule. Ausbaustufe 2 (fachlich ausgearbeitet): backoffice-portal bekam das Case-Aggregat und den CaseWorkflowService, api-client einen formalen BackendGateway-Port (Dependency Inversion für customer-portal und backoffice-portal) — 6 weitere Tests, macht 28 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, jetzt mit einem vollständig durchlaufenen Fall-Workflow).