Master 1.1

Master 1.1 Lernbuch Desktop

Markdown und HTML wurden synchron erzeugt. Die Beschreibungen sind direkt in den Projektordnern integriert.

Master 1.1 Modern Enterprise Maven Modular Projekte

Projektbeschreibungen und Ablauf Master 1.1

Dieses Dokument beschreibt, was die Maven-Module in Master 1 tun und wie der Ablauf durch die Versionen funktioniert. Die gleichen Kurzbeschreibungen sind direkt in den jeweiligen Modulordnern als README.md und README.html integriert.

Gesamtidee

Master 1 ist als Lernleiter aufgebaut: V01 beginnt mit klarer Modularisierung, V02 vertieft Clean Architecture, V03 fuegt Outbox und Events hinzu, V04 zeigt Security/Observability, V05 fuehrt Richtung Cloud-Native Betrieb.

End-to-End-Ablauf ueber die Lernleiter

  1. V01: Bestellung wird ueber Controller angenommen, Application Use Case erzeugt Domain-Order und speichert ueber Repository-Port.
  2. V02: Derselbe Ablauf wird sauberer ueber DTO, Mapper, Facade, Use Cases und Ports strukturiert.
  3. V03: Die Bestellung erzeugt Domain Events; OutboxRecord und Publisher sichern die spaetere Event-Auslieferung.
  4. V04: Query- und Service-Aufrufe werden ueber Security Proxy, Approval Policies, Audit und Metrics abgesichert und beobachtbar gemacht.
  5. V05: Command- und Query-Seite werden getrennt; Saga, Billing Gateway, Legacy Adapter und OpenShift/Kubernetes-Artefakte zeigen den Betriebspfad.

Moduluebersicht

Modul Typ Was es tut Ablaufrolle
v01-modular-baseline/order-domain Domain-Modul Enthaelt das einfache Bestellmodell mit Wertobjekten, Status und grundlegenden Invarianten. Application erzeugt eine Order ueber fachliche Methoden.; Order prueft Invarianten und wechselt den Status.
v01-modular-baseline/order-application Use-Case-Modul Definiert den einfachen Bestell-Use-Case und die Ports, ueber die Domain und Adapter verbunden werden. Controller erstellt ein PlaceOrderCommand.; Use Case erzeugt Domain-Objekte und nutzt PricingPolicy.
v01-modular-baseline/order-adapter-memory Outbound Adapter Stellt eine einfache In-Memory-Persistenz bereit, damit die Modulgrenzen ohne echte Datenbank sichtbar werden. Use Case ruft OrderRepository.save.; InMemoryOrderRepository speichert die Order im Speicher.
v01-modular-baseline/order-app Bootstrap / Inbound Adapter Startet die einfache Anwendung und stellt einen REST-nahen Einstieg in den Bestellprozess dar. HTTP/Controller-Aufruf kommt herein.; Controller baut ein Command.
v02-clean-architecture-deep-dive/order-domain Clean-Domain Vertieft die Domain mit sauberer Trennung von CustomerId, OrderId und Order-Aggregate. Use Case erstellt Domain-Objekte.; Domain enthaelt nur Regeln und Zustandswechsel.
v02-clean-architecture-deep-dive/order-application Use-Case- und Port-Schicht Zeigt Clean Architecture mit Commands, Use Cases und Repository-Port. Inbound Adapter uebergibt Command.; Use Case steuert fachlichen Ablauf.
v02-clean-architecture-deep-dive/order-adapters Inbound/Outbound Adapter Kapselt REST, DTO-Mapping, Facade und In-Memory-Persistenz als technische Raender. REST empfaengt Request.; DTO Mapper uebersetzt in Command.
v02-clean-architecture-deep-dive/order-bootstrap Runtime Composition Verdrahtet Clean-Architecture-Bausteine in einer lauffaehigen Startkonfiguration. Application startet.; Bootstrap erzeugt/verdrahtet Use Cases und Adapter.
v03-event-driven-outbox-deep-dive/order-domain Event-faehige Domain Erweitert die Bestellung um Domain Events und OrderPlaced als fachliches Ereignis. Order wird platziert.; Domain erzeugt OrderPlaced.
v03-event-driven-outbox-deep-dive/order-application Use Case + Outbox Port Verbindet Bestellablauf mit Outbox-Records, Publisher-Template und Ports fuer robuste Event-Auslieferung. PlaceOrderUseCase speichert Order.; OutboxRecord wird erzeugt.
v03-event-driven-outbox-deep-dive/order-outbox-adapter Messaging/Outbox Adapter Implementiert Outbox-Repository und idempotente Nachrichtenverarbeitung als lernbare Infrastrukturgrenze. Application speichert OutboxRecord.; DefaultOutboxPublisher liest und publiziert.
v03-event-driven-outbox-deep-dive/order-bootstrap Runtime Composition Startet die V03-Variante mit Domain Events und Outbox-Fluss. Runtime startet V03.; Use Case erzeugt Bestellung und Outbox.
v04-security-observability-deep-dive/order-core Core Query/Rules Buendelt Query-Service und Spezifikationen als fachlichen Kern fuer Security- und Observability-Dekorationen. Query wird angefordert.; Security Proxy prueft Zugriff.
v04-security-observability-deep-dive/order-security Security Boundary Zeigt Zugriffskontrolle, Approval Policies und Security Proxy rund um fachliche Services. Client ruft Query/Approval an.; Security Proxy prueft Context.
v04-security-observability-deep-dive/order-observability Audit/Metrics Decorator Fuegt Audit und Metriken hinzu, ohne den Kernservice mit Querschnittslogik zu vermischen. Service-Aufruf geht durch Decorator.; Audit zeichnet fachlichen Zugriff auf.
v04-security-observability-deep-dive/order-bootstrap Runtime Composition Verdrahtet Core, Security und Observability zu einer nachvollziehbaren Laufzeitvariante. Runtime startet V04.; Services werden mit Proxy und Decorator verbunden.
v05-cloud-native-ops-deep-dive/order-command Command/CQRS Write Side Enthaelt die schreibende Seite fuer Bestellungen mit Command Handler und SubmitOrderCommand. API erzeugt SubmitOrderCommand.; Command Handler validiert und verarbeitet.
v05-cloud-native-ops-deep-dive/order-query CQRS Read Side Zeigt ein separates Lesemodell und Query Handler fuer schnelle fachliche Abfragen. API fragt Query Handler.; Read Model liefert optimierte Sicht.
v05-cloud-native-ops-deep-dive/order-integration Legacy/Process Integration Kapselt Billing-Anbindung und Fulfillment-Prozess als Gateway, ACL und Saga. Command-Seite loest Integration aus.; Saga ruft BillingGateway.
v05-cloud-native-ops-deep-dive/order-runtime Cloud-Native Runtime Stellt API und Startklasse fuer die cloud-native Variante bereit. Container startet Runtime.; OrderApi nimmt Requests an.

Lese-Reihenfolge

  1. versions/v01-modular-baseline/PROJECTS.html fuer die Basis.
  2. versions/v02-clean-architecture-deep-dive/PROJECTS.html fuer Ports, Mapper und Use Cases.
  3. versions/v03-event-driven-outbox-deep-dive/PROJECTS.html fuer Events und Outbox.
  4. versions/v04-security-observability-deep-dive/PROJECTS.html fuer Security und Observability.
  5. versions/v05-cloud-native-ops-deep-dive/PROJECTS.html fuer CQRS, Saga und Cloud Native.

Wichtigste Entwurfsmuster im Master-1-Ablauf

  • Aggregate Root: Order schuetzt Konsistenz.
  • Value Object: Money, OrderId, CustomerId machen Fachbegriffe typisiert.
  • Command Pattern: Commands transportieren Use-Case-Wuensche.
  • Application Service: Use Cases orchestrieren ohne Infrastrukturdetails.
  • Ports and Adapters: Application kennt Ports; Adapter implementieren Technik.
  • DTO + Mapper: Web-/API-Modelle werden von Domain-Modellen getrennt.
  • Facade: vereinfacht Zugriff auf mehrere Use Cases.
  • Transactional Outbox: Event-Auslieferung wird robust vorbereitet.
  • Idempotent Consumer: doppelte Nachrichten werden abgefangen.
  • Proxy/Decorator/Policy: Security und Observability bleiben sauber vom Kern getrennt.
  • CQRS + Saga + Anti-Corruption Layer: V05 zeigt getrennte Lese-/Schreibmodelle und Legacy-Integration.

Architekturüberblick

Zielbild

Das Paket zeigt, wie ein modernes Enterprise-Java-System als Maven-Multi-Module-Workspace aufgebaut werden kann. Die fachliche Domäne bleibt stabil, während Adapter, Infrastruktur und Frameworks austauschbar bleiben.

API / Adapter  ->  Application / Use Cases  ->  Domain Model
                       ^                          |
                       |                          v
                  Ports / Contracts        Domain Events
                       |
                       v
            Persistence, Messaging, Security, Ops

Modulregeln

Regel Erklärung
Domain kennt keine Frameworks Geschäftslogik soll unabhängig von Spring, REST, Datenbank und Messaging bleiben.
Application koordiniert Use Cases Transaktionen, Validierung und Ports werden auf Anwendungsebene orchestriert.
Adapter implementieren Ports REST, Persistence, Messaging und externe Systeme hängen außen.
Bootstrap verbindet alles Spring Boot oder andere Runtime-Konfiguration startet das System.
Events verlassen die Domain kontrolliert Domain Events werden über Application/Outbox veröffentlicht, nicht direkt aus Entities.

Kompakte fachliche SVG-Idee

Die SVGs in docs/assets/ erklären die Modulrichtung, Outbox-Verarbeitung und Cloud-Native Deploymentkette.

Entwurfsmuster-Dokumentation

Alle im Maven-/Java-Code verwendeten Muster sind hier zentral dokumentiert. Im Code sind sie zusätzlich mit // PATTERN: markiert.

Priorität Pattern Zweck Einsatzort Begründung
10 Hexagonal Architecture / Ports & Adapters Fachkern von Infrastruktur entkoppeln alle Versionen, besonders application/ports und adapters Enterprise-Systeme müssen Datenbank, API, Messaging und externe Systeme austauschen können.
10 Repository Persistenz hinter fachlicher Schnittstelle kapseln OrderRepository, InMemoryOrderRepository Die Application-Schicht arbeitet gegen Ports, nicht gegen Datenbankdetails.
10 Aggregate Konsistenzgrenzen in der Domain bündeln Order Geschäftsregeln liegen am fachlichen Objekt, nicht verstreut in Services.
9 Value Object unveränderliche fachliche Werte modellieren OrderId, Money, CustomerId Werte werden sicherer, testbarer und ausdrucksstärker.
9 Factory Method gültige fachliche Objekte erzeugen Order.open(...), OrderLine.of(...) Erzeugungslogik schützt Invarianten.
9 Command Use-Case-Eingaben explizit modellieren PlaceOrderCommand, ApproveOrderCommand Eingaben sind stabiler als lose Parameterlisten.
9 Application Service / Use Case fachliche Abläufe koordinieren PlaceOrderUseCase, ApproveOrderUseCase Orchestrierung bleibt getrennt von Domain-Entscheidungen.
8 Strategy austauschbare Geschäftsregel PricingPolicy Rabatte/Preise können wechseln, ohne Use Case zu verändern.
8 Adapter externe Systeme an interne Ports anpassen REST Controller, Persistence Adapter, Messaging Adapter Framework-Code bleibt an der Außenseite.
8 Facade komplexe Teilsysteme vereinfachen OrderFacade API-Schicht bekommt eine stabile, einfache Oberfläche.
8 Mapper DTOs und Domain trennen OrderDtoMapper REST-/JSON-Modelle verschmutzen nicht die Domain.
8 Observer / Domain Event Änderungen als Ereignisse ausdrücken DomainEvent, OrderPlaced Nachgelagerte Prozesse können reagieren, ohne den Kern eng zu koppeln.
8 Outbox Pattern Event-Publishing zuverlässig machen OutboxRecord, OutboxRepository Datenänderung und Event werden in einer Transaktionsgrenze vorbereitet.
7 Template Method Ablaufrahmen mit variablen Schritten OutboxPublisherTemplate Wiederholbarer Publish-Prozess mit spezialisierten Implementierungen.
7 Decorator Querschnittsfunktion ergänzen AuditedOrderService Audit/Metrik kann ergänzt werden, ohne Use Case umzuschreiben.
7 Chain of Responsibility Security-/Policy-Prüfungen verketten ApprovalPolicyChain Mehrere Regeln bleiben einzeln testbar.
7 Proxy Zugriff kontrollieren oder messen SecuredOrderQueryProxy Security/Logging können vor Fachzugriff gelegt werden.
7 Specification fachliche Auswahlregel ausdrücken HighValueOrderSpecification Komplexe Filterregeln werden benannt und testbar.
7 CQRS Schreib- und Lesemodelle trennen V05 command und query Enterprise-Systeme brauchen oft andere Modelle für Schreiben, Lesen und Reporting.
7 Saga / Process Manager verteilte Fachprozesse steuern OrderFulfillmentSaga Lange Prozesse über mehrere Systeme werden nachvollziehbar orchestriert.
7 Anti-Corruption Layer fremde Modelle abschirmen LegacyBillingClientAdapter Legacy- oder Fremdsysteme sollen das eigene Domain-Modell nicht vergiften.
7 Circuit Breaker Boundary externe Aufrufe absichern BillingGateway Ausfälle externer Systeme dürfen nicht unkontrolliert in den Kern laufen.

Grundregel

Je weiter innen eine Klasse liegt, desto weniger technische Abhängigkeiten darf sie haben. Je weiter außen eine Klasse liegt, desto stärker darf sie Frameworks, Datenbanken, Messaging oder Cloud-APIs kennen.

Deep-Dive-Roadmap

V01 - Modular Baseline

Lerne zuerst die Maven-Modulgrenzen: domain, application, adapter, app. Der Kern ist bewusst klein, damit Abhängigkeiten und Richtung verständlich bleiben.

V02 - Clean Architecture Deep Dive

Vertieft Ports & Adapters, Use Cases, Mapper, DTO-Grenzen und Testbarkeit. Wichtige Frage: Was darf von innen nach außen wissen?

V03 - Event-Driven Outbox Deep Dive

Fügt Domain Events, Outbox Records und Publisher hinzu. Wichtige Frage: Wie vermeidet man verlorene Events zwischen Datenbanktransaktion und Messaging?

V04 - Security & Observability Deep Dive

Zeigt Security Boundary, Audit Trail, Metrics und Logging-nahe Strukturen. Wichtige Frage: Wo gehören technische Querschnittsthemen hin, ohne die Domain zu verschmutzen?

V05 - Cloud-Native Ops Deep Dive

Zeigt Kubernetes/OpenShift-Manifeste, Dockerfile, Health Checks, CQRS, Saga und Resilience-Schnittstellen. Wichtige Frage: Wie bleibt Enterprise-Architektur betreibbar, skalierbar und beobachtbar?

Nächste Ausbauideen

  1. echte PostgreSQL-Testcontainers ergänzen
  2. Kafka/RabbitMQ Outbox-Publisher ergänzen
  3. OpenAPI Contract Tests ergänzen
  4. Keycloak/OIDC Security integrieren
  5. OpenTelemetry Tracing ergänzen
  6. Helm/Kustomize-Varianten ergänzen
  7. Migration von Legacy SOAP/EJB zu Adapter-Layer zeigen
⌂ Cockpit