◎
Fachlicher Zweck
Der Abschlussmaster verbindet Portal, Gateway, Fachsysteme, Legacy-Adapter und Observability zu einem End-to-End-Bild.
Master 25 - Consolidated End-to-End Runtime
Abschlussnaher Master: verbindet Portal, Gateway, Fachsysteme, Legacy, Container-Plattform und Observability zu einem erklaerten End-to-End-Bild.
Wozu?
Master 25 macht die vielen bisherigen Master als Gesamtplattform verstaendlich.
Was laeuft?
Ein Java-Smoke-Flow simuliert Portal -> Gateway -> Insurance -> Banking -> ERP -> Logistics -> Legacy -> Audit.
Was ist wichtig?
Nicht mehr nur Inhalt erweitern, sondern Startbarkeit, Orientierung, Qualitaet und Abschlussreife verbessern.
cd mvn-ws-impl-e2e
mvn -q -pl runnable-smoke -am package exec:javaLehrbuch und Praxis
Schnellüberblick in Kacheln
⚙
Technischer Fokus
Gesamtablauf, Zusammenspiel, Laufzeitbild, Abschlussqualität
▣
Domäne / Kontext
End-to-End Plattform
☑
Zielgruppe
Alle, die das große Ganze als zusammenhängende Plattform verstehen wollen
Kompaktes SVG zum Verständnis
Das SVG soll nicht jedes technische Detail zeigen, sondern die Hauptbewegung des Projekts erklären. So sieht man schnell, wie aus Eingangsdaten, Fachregeln und technischen Bausteinen ein sinnvoller Ablauf entsteht.
Wie man dieses Lehrbuch am besten liest
1
1. Einstieg
Zuerst die Kurzbeschreibung und die Kacheln lesen, damit sofort klar ist, was dieses Projekt fachlich und technisch leisten soll.
2
2. Ablauf verstehen
Danach das SVG lesen. Es zeigt den roten Faden des Projekts und hilft, Klassen und Module später besser einzuordnen.
3
3. Technische Bausteine
Im dritten Schritt die Hauptbausteine lesen: Domain, Use Cases, Adapter, Runtime, Infrastruktur und Qualitätssicherung.
4
4. Im Projekt nachschlagen
Zum Schluss README, Projektbeschreibung, Design Patterns und RUNNABLE-Dokument öffnen und die Aussagen mit dem Projekt abgleichen.
Hinweis: Dieses Lehrbuch gehört direkt zum jeweiligen Master-Projekt und ergänzt README, Projektbeschreibungen und Design-Pattern-Dokumente.
Wichtige Bausteine und Bedeutung
| Baustein | Bedeutung | Worauf achten? |
|---|---|---|
| Fachlicher Ablauf | Beschreibt den Geschäftskontext und die Reihenfolge der zentralen Schritte. | Begriffe sauber lesen; hier steckt der eigentliche Nutzen des Systems. |
| Domänenmodell | Enthält Entitäten, Aggregate, Policies, Services oder ähnliche Kernelemente. | Wichtig ist die Trennung zwischen Fachlogik und technischer Umgebung. |
| Use Cases / Application Layer | Hier werden fachliche Aktionen orchestriert und Regeln zusammengeführt. | Achte auf Ein- und Ausgaben, Zuständigkeiten und Fehlerszenarien. |
| Adapter / Integration | Verbindung nach außen: Datenbank, Messaging, Files, APIs oder Plattform. | Adapter sollen austauschbar bleiben und nicht die Fachlogik dominieren. |
| Runtime / Start | Spring Boot, Jakarta Runtime oder runnable-smoke machen das Projekt ausführbar. | Wichtig sind Startpunkte, Ports, Profile und lokale Demo-Lauffähigkeit. |
| Qualität / Betrieb | Tests, CI/CD, Observability, Security oder Infrastruktur ergänzen die technische Reife. | Gerade hier sieht man, wie nah ein Demo-System an ein reales System herankommt. |
Ein Spur mehr Erklärung
Warum dieser Master wichtig ist: Der Abschlussmaster verbindet Portal, Gateway, Fachsysteme, Legacy-Adapter und Observability zu einem End-to-End-Bild. Im Unterschied zu kleineren Demo-Abschnitten ist hier besonders gut sichtbar, wie fachliche Regeln, technische Grenzen und Betriebsaspekte zusammenkommen.
➤
Typischer Lerngewinn
Man lernt nicht nur die Oberfläche des Themas, sondern versteht Zusammenhänge zwischen Fachlichkeit, Architektur und Betrieb.
➤
Worauf man achten sollte
Wichtig sind Modulgrenzen, klare Namensgebung, nachvollziehbare Abläufe und der Unterschied zwischen Demo- und produktionsnahen Aspekten.
Weiter im Projekt
Wenn du nach diesem Lehrbuch tiefer einsteigen willst, öffne als Nächstes die folgenden Projektdateien. So wechselst du von der didaktischen Sicht in die eigentliche Projektstruktur.
Module und Quellcode
5 Module4 KategorienInhalte vollständig übernommen
API & Application 2
api-contractsAPI & Application
Verantwortung
Definiert stabile, framework-neutrale Verträge für Correlation ID und beobachtbare Schritte des End-to-End-Ablaufs.
Entwurfsmuster und Architekturbausteine
- Value Object: CorrelationId validiert und transportiert die fachlich stabile Korrelationskennung.
- Result Object: E2eStep beschreibt ein Ergebnis ohne Kopplung an eine konkrete Runtime.
e2e-orchestratorAPI & Application
Verantwortung
Orchestriert den fachlichen Demonstrationsfluss über Portal, Gateway, Versicherung, Banking, ERP, Logistik, Legacy und Observability.
Entwurfsmuster und Architekturbausteine
- Facade: Eine einfache run-Methode kapselt den komplexen systemübergreifenden Ablauf.
- Pipeline: Jeder Schritt ergänzt dieselbe nachvollziehbare End-to-End-Geschichte.
Runtime 1
enterprise-e2e-orchestratorRuntime
Verantwortung
Bietet eine startbare Spring-Boot-Runtime mit REST-Eingang und zustandsbehaftetem Fulfilment-Prozessmanager.
Entwurfsmuster und Architekturbausteine
- Composition Root: EnterpriseE2eApplication startet und verdrahtet die Runtime.
- Process Manager: FulfilmentJourney kontrolliert erlaubte Ereignisfolgen und Kompensation.
- Inbound Adapter: JourneyController übersetzt HTTP-Aufrufe in den Prozesszustand.
Testing 1
runnable-smokeTesting
Verantwortung
Startet den konsolidierten Ablauf ohne Webserver und liefert einen schnellen, lesbaren Smoke-Nachweis über alle Demo-Schritte.
Entwurfsmuster und Architekturbausteine
- Command: RunnableSmokeApp bildet einen eindeutigen ausführbaren Einstiegspunkt.
- Smoke Test: Der Lauf prüft mit minimalem Aufwand, ob Verträge und Orchestrator gemeinsam funktionieren.
Referenzimplementierung 1
enterprise-reference-sliceReferenzimplementierung
Verantwortung
Zeigt eine ausführbare vertikale Referenz mit Idempotenz, Outbox-/Inbox-Verarbeitung, Retry-Verhalten und zugehörigen JUnit-Tests.
Entwurfsmuster und Architekturbausteine
- Vertical Slice: API-Befehl, Persistenzidee, Outbox und Inbox werden als durchgängiger Ablauf demonstriert.
- Transactional Outbox: Ausgehende Ereignisse werden als eigener zuverlässiger Zustand geführt.
- Idempotent Consumer: Inbox und Business Key verhindern doppelte Verarbeitung.