Master Maven Modular

Aydin Modern Enterprise Maven Master

Moderner Enterprise-Java-Workspace mit Deep-Dive-Versionen, Maven Multi-Module-Struktur, Clean Architecture, Outbox, Security, Observability, CQRS, Saga und Cloud-Native-Betrieb.

Desktop HTMLiPhone/Safari HTMLDesign PatternsPrüfberichtLehrbuch

Versionen

V01 Modular Baseline

Domain, Application, Repository Port, Memory Adapter, REST Bootstrap.

öffnen

V02 Clean Architecture

Use Cases, Ports, Mapper, Facade, DTO-Grenzen.

öffnen

V03 Event Outbox

Domain Events, Outbox Records, Publisher Template, Idempotenz.

öffnen

V04 Security Observability

Proxy, Chain, Decorator, Specification, Audit und Metrics.

öffnen

V05 Cloud Native Ops

CQRS, Saga, Anti-Corruption Layer, Kubernetes/OpenShift.

öffnen

Fachliche Darstellung

Modulgrenzen

Codeblock-Beispiel


// PATTERN: Repository Port
public interface OrderRepository {
    void save(Order order);
    Optional<Order> findById(OrderId id);
}

// PATTERN: Aggregate Root
public final class Order {
    public void submit() {
        if (lines.isEmpty()) throw new IllegalStateException("Order must contain lines");
        status = OrderStatus.SUBMITTED;
    }
}

Runnable Smoke-Test

Dieser Master enthaelt jetzt ein direkt ausfuehrbares Maven-Modul runnable-smoke.

Runnable-Anleitung oeffnen

Lehrbuch und Praxis

Was lerne ich hier?

◎

Fachlicher Kern

Java/Maven

⚙

Technischer Fokus

Von Build-Struktur zu fachlich getrennten Modulen.

★

Warum wichtig?

Saubere Maven-Multi-Module-Struktur, Modulgrenzen, erste Spring-Boot-Starts und Smoke-Flows.

✓

Lernziel

Du erkennst Zweck, Ablauf, Modulgrenzen und Betriebsbezug dieses Masters.

Fachliches Mini-Szenario

Szenario: Dieser Master zeigt einen fokussierten Lernabschnitt: Saubere Maven-Multi-Module-Struktur, Modulgrenzen, erste Spring-Boot-Starts und Smoke-Flows. Der Ablauf ist so aufgebaut, dass man zuerst Zweck und Kontext versteht, danach Module und Runtime liest und erst anschließend tiefer in Code, Muster und Infrastruktur einsteigt.
?

Fachliche Frage

Welche Geschäftsentscheidung wird hier unterstützt und welche Daten müssen nachvollziehbar bleiben?

?

Technische Frage

Welche Module sind wirklich Fachkern und welche sind nur Adapter, Runtime oder Infrastruktur?

Fachliches und technisches SVG

Fachlicher AblaufZielbildModuleAblaufRuntimeQualität
Technischer AblaufREST/APIUse CaseDomainRepositoryOutbox/EventAdapter

Die zwei SVGs trennen bewusst Fachlichkeit und Technik. Dadurch sieht man, ob ein Thema wirklich fachlich ist oder nur eine technische Umsetzungsschicht darstellt.

Modulkarte

Domain / Fachmodell
Application / Use Cases
Adapter / Infrastruktur
Runtime / Start
Qualität / Betrieb
Dokumentation / Lernen
Leseregel: Starte immer beim Fachmodell und gehe erst danach in Adapter, Runtime und Plattform. So bleibt die Architektur verständlich.

Start, Runtime und praktische Nutzung

▶

Schnellstart

Öffne RUNNABLE.html oder nutze den Smoke-Start im jeweiligen Workspace.

☕

Spring/Jakarta

Wo vorhanden, ergänzen Spring Boot oder Jakarta eine echte Runtime. Smoke bleibt der robuste Minimalstart.

▣

Container

Bei Container-Mastern helfen Compose, Kubernetes und OpenShift-Profile beim Betriebsverständnis.

mvn -q -pl runnable-smoke -am package exec:java

Was ist Demo, was wäre Produktion?

  • Demo: lokale Startbarkeit, vereinfachte Adapter, nachvollziehbare Abläufe.
  • Produktionsnah: klare Modulgrenzen, dokumentierte Patterns, Container-/Runtime-Profile und Betriebsdenken.
  • Noch zu ergänzen für echte Produktion: echte Secrets, echte Infrastruktur, Security-Härtung, Lasttests und verbindliche Compliance-Vorgaben.

Weiter im Projekt

Diese Links führen aus dem Lehrbuch in die eigentliche Projektstruktur.

README RUNNABLE Projektbeschreibungen Design Patterns
Final UI & Lehrbuch Upgrade · Kacheln, zwei SVG-Perspektiven, Mini-Szenario und bessere Leseführung.

Module und Quellcode

Du bist hierMVN SB3 Modulare GrundlageModule
30 Module8 KategorienInhalte vollständig übernommen

API & Application 2

order-applicationAPI & Application
Codepfad: versions/v01-modular-baseline/order-application

V01 Order Application

Kurzbeschreibung

Modultyp: Use-Case-Modul

Definiert den einfachen Bestell-Use-Case und die Ports, ueber die Domain und Adapter verbunden werden.

Was macht das Modul?

  • definiert PlaceOrderCommand und PlaceOrderUseCase
  • enthaelt OrderRepository als Port
  • enthaelt PricingPolicy als austauschbare Preisregel

Ablauf im Gesamtsystem

  1. Controller erstellt ein PlaceOrderCommand.
  2. Use Case erzeugt Domain-Objekte und nutzt PricingPolicy.
  3. OrderRepository-Port wird vom Memory Adapter umgesetzt.

Wichtige Klassen und Dateien

  • PlaceOrderCommand
  • PlaceOrderUseCase
  • OrderRepository
  • PricingPolicy
  • DefaultPricingPolicy

Verwendete Entwurfsmuster

  • Application Service
  • Command Pattern
  • Repository Port
  • Strategy Pattern

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-applicationAPI & Application
Codepfad: versions/v02-clean-architecture-deep-dive/order-application

V02 Order Application

Kurzbeschreibung

Modultyp: Use-Case- und Port-Schicht

Zeigt Clean Architecture mit Commands, Use Cases und Repository-Port.

Was macht das Modul?

  • definiert CreateOrderCommand
  • definiert CreateOrderUseCase und ApproveOrderUseCase
  • haelt OrderRepository als Port in der Application-Schicht

Ablauf im Gesamtsystem

  1. Inbound Adapter uebergibt Command.
  2. Use Case steuert fachlichen Ablauf.
  3. Repository-Port isoliert Persistenz.

Wichtige Klassen und Dateien

  • CreateOrderCommand
  • CreateOrderUseCase
  • ApproveOrderUseCase
  • OrderRepository

Verwendete Entwurfsmuster

  • Use Case Interface
  • Command Pattern
  • Port Pattern

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.

Adapter & Integration 3

order-adapter-memoryAdapter & Integration
Codepfad: versions/v01-modular-baseline/order-adapter-memory

V01 Memory Adapter

Kurzbeschreibung

Modultyp: Outbound Adapter

Stellt eine einfache In-Memory-Persistenz bereit, damit die Modulgrenzen ohne echte Datenbank sichtbar werden.

Was macht das Modul?

  • implementiert OrderRepository
  • speichert Orders in einer Map
  • zeigt Adapterprinzip ohne Infrastrukturkomplexitaet

Ablauf im Gesamtsystem

  1. Use Case ruft OrderRepository.save.
  2. InMemoryOrderRepository speichert die Order im Speicher.
  3. Tests oder Demo-Aufrufe koennen ohne Datenbank laufen.

Wichtige Klassen und Dateien

  • InMemoryOrderRepository

Verwendete Entwurfsmuster

  • Adapter Pattern
  • Repository Adapter
  • Fake Adapter for Learning

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-adaptersAdapter & Integration
Codepfad: versions/v02-clean-architecture-deep-dive/order-adapters

V02 Order Adapters

Kurzbeschreibung

Modultyp: Inbound/Outbound Adapter

Kapselt REST, DTO-Mapping, Facade und In-Memory-Persistenz als technische Raender.

Was macht das Modul?

  • stellt REST Controller und DTO bereit
  • uebersetzt DTOs ueber Mapper
  • stellt OrderFacade als vereinfachte API-Grenze bereit

Ablauf im Gesamtsystem

  1. REST empfaengt Request.
  2. DTO Mapper uebersetzt in Command.
  3. Facade ruft Use Case und Repository Adapter.

Wichtige Klassen und Dateien

  • OrderController
  • OrderDto
  • OrderDtoMapper
  • OrderFacade
  • InMemoryOrderRepository

Verwendete Entwurfsmuster

  • Adapter Pattern
  • DTO
  • Mapper
  • Facade

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-integrationAdapter & Integration
Codepfad: versions/v05-cloud-native-ops-deep-dive/order-integration

V05 Order Integration

Kurzbeschreibung

Modultyp: Legacy/Process Integration

Kapselt Billing-Anbindung und Fulfillment-Prozess als Gateway, ACL und Saga.

Was macht das Modul?

  • definiert BillingGateway
  • implementiert LegacyBillingClientAdapter
  • koordiniert OrderFulfillmentSaga

Ablauf im Gesamtsystem

  1. Command-Seite loest Integration aus.
  2. Saga ruft BillingGateway.
  3. LegacyBillingClientAdapter uebersetzt zur alten Billing-Welt.

Wichtige Klassen und Dateien

  • BillingGateway
  • LegacyBillingClientAdapter
  • OrderFulfillmentSaga

Verwendete Entwurfsmuster

  • Saga
  • Gateway
  • Anti-Corruption Layer
  • Adapter Pattern

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.

Domain 2

order-domainDomain
Codepfad: versions/v01-modular-baseline/order-domain

V01 Order Domain

Kurzbeschreibung

Modultyp: Domain-Modul

Enthaelt das einfache Bestellmodell mit Wertobjekten, Status und grundlegenden Invarianten.

Was macht das Modul?

  • modelliert Order, OrderLine, OrderId, Money und OrderStatus
  • erzwingt Mindestregeln wie Positionen vor Submit
  • bleibt frei von Spring, Web und Persistenz

Ablauf im Gesamtsystem

  1. Application erzeugt eine Order ueber fachliche Methoden.
  2. Order prueft Invarianten und wechselt den Status.
  3. Repository-Port speichert das Aggregate ueber einen Adapter.

Wichtige Klassen und Dateien

  • Order
  • OrderLine
  • OrderId
  • Money
  • OrderStatus
  • OrderTest

Verwendete Entwurfsmuster

  • Aggregate Root
  • Value Object
  • Entity
  • Domain Model

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-domainDomain
Codepfad: versions/v02-clean-architecture-deep-dive/order-domain

V02 Order Domain

Kurzbeschreibung

Modultyp: Clean-Domain

Vertieft die Domain mit sauberer Trennung von CustomerId, OrderId und Order-Aggregate.

Was macht das Modul?

  • zeigt Domain ohne Framework-Abhaengigkeit
  • trennt IDs als fachliche Typen
  • bereitet Use Cases und Adaptergrenzen vor

Ablauf im Gesamtsystem

  1. Use Case erstellt Domain-Objekte.
  2. Domain enthaelt nur Regeln und Zustandswechsel.
  3. Adapter greifen nicht direkt in Domain-Interna ein.

Wichtige Klassen und Dateien

  • Order
  • OrderId
  • CustomerId

Verwendete Entwurfsmuster

  • Aggregate Root
  • Value Object
  • Clean Domain Model

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.

Infrastructure 1

order-runtimeInfrastructure
Codepfad: versions/v05-cloud-native-ops-deep-dive/order-runtime

V05 Order Runtime

Kurzbeschreibung

Modultyp: Cloud-Native Runtime

Stellt API und Startklasse fuer die cloud-native Variante bereit.

Was macht das Modul?

  • enthaelt V05Application
  • stellt OrderApi bereit
  • verbindet Command, Query und Integration

Ablauf im Gesamtsystem

  1. Container startet Runtime.
  2. OrderApi nimmt Requests an.
  3. Commands, Queries und Integration laufen ueber getrennte Bausteine.

Wichtige Klassen und Dateien

  • V05Application
  • OrderApi

Verwendete Entwurfsmuster

  • API Adapter
  • Composition Root
  • Modular Runtime

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.

Messaging 5

v03-event-driven-outbox-deep-diveMessaging
Codepfad: versions/v03-event-driven-outbox-deep-dive

v03-event-driven-outbox-parent

Eigener Maven-Multi-Module-Workspace.

Start

cd versions/v03-event-driven-outbox-deep-dive
mvn test
mvn package

Modulrichtung

adapters / app -> application -> domain

Muster sind im Code mit // PATTERN: kommentiert und zentral in ../../docs/design-patterns.md dokumentiert.

Projektbeschreibung und Modulablauf

Diese Version enthaelt jetzt eine direkte Ablaufbeschreibung:

  • PROJECTS.md / PROJECTS.html: Gesamtuebersicht der Module dieser Version.
  • Jedes Maven-Modul besitzt ein eigenes README.md und README.html mit Zweck, Ablauf, wichtigen Klassen und Entwurfsmustern.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-applicationMessaging
Codepfad: versions/v03-event-driven-outbox-deep-dive/order-application

V03 Outbox Application

Kurzbeschreibung

Modultyp: Use Case + Outbox Port

Verbindet Bestellablauf mit Outbox-Records, Publisher-Template und Ports fuer robuste Event-Auslieferung.

Was macht das Modul?

  • definiert OutboxRecord und OutboxRepository
  • definiert MessagePublisher als Port
  • stellt OutboxPublisherTemplate bereit

Ablauf im Gesamtsystem

  1. PlaceOrderUseCase speichert Order.
  2. OutboxRecord wird erzeugt.
  3. Template publiziert ueber MessagePublisher.

Wichtige Klassen und Dateien

  • PlaceOrderUseCase
  • OutboxRecord
  • OutboxRepository
  • MessagePublisher
  • OutboxPublisherTemplate
  • OrderRepository

Verwendete Entwurfsmuster

  • Transactional Outbox
  • Template Method
  • Publisher Port
  • Application Service

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-bootstrapMessaging
Codepfad: versions/v03-event-driven-outbox-deep-dive/order-bootstrap

V03 Order Bootstrap

Kurzbeschreibung

Modultyp: Runtime Composition

Startet die V03-Variante mit Domain Events und Outbox-Fluss.

Was macht das Modul?

  • enthaelt V03Application
  • verdrahtet Outbox-Anwendung und Adapter
  • macht Event-Fluss ausfuehrbar nachvollziehbar

Ablauf im Gesamtsystem

  1. Runtime startet V03.
  2. Use Case erzeugt Bestellung und Outbox.
  3. Publisher wird ueber Adapter eingebunden.

Wichtige Klassen und Dateien

  • V03Application

Verwendete Entwurfsmuster

  • Composition Root
  • Event-Driven Runtime

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-domainMessaging
Codepfad: versions/v03-event-driven-outbox-deep-dive/order-domain

V03 Event Domain

Kurzbeschreibung

Modultyp: Event-faehige Domain

Erweitert die Bestellung um Domain Events und OrderPlaced als fachliches Ereignis.

Was macht das Modul?

  • definiert DomainEvent
  • erzeugt OrderPlaced
  • macht Event-Sprache fachlich sichtbar

Ablauf im Gesamtsystem

  1. Order wird platziert.
  2. Domain erzeugt OrderPlaced.
  3. Application uebernimmt Event fuer Outbox-Verarbeitung.

Wichtige Klassen und Dateien

  • DomainEvent
  • Order
  • OrderPlaced

Verwendete Entwurfsmuster

  • Domain Event
  • Aggregate Root
  • Event Modeling

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-outbox-adapterMessaging
Codepfad: versions/v03-event-driven-outbox-deep-dive/order-outbox-adapter

V03 Outbox Adapter

Kurzbeschreibung

Modultyp: Messaging/Outbox Adapter

Implementiert Outbox-Repository und idempotente Nachrichtenverarbeitung als lernbare Infrastrukturgrenze.

Was macht das Modul?

  • stellt InMemoryOutboxRepository bereit
  • publiziert Events ueber DefaultOutboxPublisher
  • verhindert Doppelverarbeitung mit IdempotentMessagePublisher

Ablauf im Gesamtsystem

  1. Application speichert OutboxRecord.
  2. DefaultOutboxPublisher liest und publiziert.
  3. IdempotentMessagePublisher schuetzt gegen doppelte Messages.

Wichtige Klassen und Dateien

  • DefaultOutboxPublisher
  • IdempotentMessagePublisher
  • InMemoryOutboxRepository

Verwendete Entwurfsmuster

  • Outbox Relay
  • Idempotent Consumer
  • Adapter Pattern

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.

Security 5

v04-security-observability-deep-diveSecurity
Codepfad: versions/v04-security-observability-deep-dive

v04-security-observability-parent

Eigener Maven-Multi-Module-Workspace.

Start

cd versions/v04-security-observability-deep-dive
mvn test
mvn package

Modulrichtung

adapters / app -> application -> domain

Muster sind im Code mit // PATTERN: kommentiert und zentral in ../../docs/design-patterns.md dokumentiert.

Projektbeschreibung und Modulablauf

Diese Version enthaelt jetzt eine direkte Ablaufbeschreibung:

  • PROJECTS.md / PROJECTS.html: Gesamtuebersicht der Module dieser Version.
  • Jedes Maven-Modul besitzt ein eigenes README.md und README.html mit Zweck, Ablauf, wichtigen Klassen und Entwurfsmustern.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-bootstrapSecurity
Codepfad: versions/v04-security-observability-deep-dive/order-bootstrap

V04 Order Bootstrap

Kurzbeschreibung

Modultyp: Runtime Composition

Verdrahtet Core, Security und Observability zu einer nachvollziehbaren Laufzeitvariante.

Was macht das Modul?

  • enthaelt V04Application
  • kombiniert Proxy, Policies und Decorators
  • zeigt Reihenfolge von Security vor Observability oder umgekehrt

Ablauf im Gesamtsystem

  1. Runtime startet V04.
  2. Services werden mit Proxy und Decorator verbunden.
  3. Aufruf laeuft kontrolliert und beobachtbar durch die Kette.

Wichtige Klassen und Dateien

  • V04Application

Verwendete Entwurfsmuster

  • Composition Root
  • Decorator Chain

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-coreSecurity
Codepfad: versions/v04-security-observability-deep-dive/order-core

V04 Order Core

Kurzbeschreibung

Modultyp: Core Query/Rules

Buendelt Query-Service und Spezifikationen als fachlichen Kern fuer Security- und Observability-Dekorationen.

Was macht das Modul?

  • stellt OrderQueryService bereit
  • implementiert DefaultOrderQueryService
  • definiert HighValueOrderSpecification

Ablauf im Gesamtsystem

  1. Query wird angefordert.
  2. Security Proxy prueft Zugriff.
  3. Core Service liefert Daten und Specification bewertet Risiko.

Wichtige Klassen und Dateien

  • OrderQueryService
  • DefaultOrderQueryService
  • HighValueOrderSpecification

Verwendete Entwurfsmuster

  • Specification
  • Service Interface
  • Core Domain Service

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-observabilitySecurity
Codepfad: versions/v04-security-observability-deep-dive/order-observability

V04 Order Observability

Kurzbeschreibung

Modultyp: Audit/Metrics Decorator

Fuegt Audit und Metriken hinzu, ohne den Kernservice mit Querschnittslogik zu vermischen.

Was macht das Modul?

  • stellt AuditedOrderService bereit
  • stellt MeteredOrderService bereit
  • zeigt beobachtbare Service-Ketten

Ablauf im Gesamtsystem

  1. Service-Aufruf geht durch Decorator.
  2. Audit zeichnet fachlichen Zugriff auf.
  3. Metering erfasst technische Kennzahlen.

Wichtige Klassen und Dateien

  • AuditedOrderService
  • MeteredOrderService

Verwendete Entwurfsmuster

  • Decorator Pattern
  • Audit Trail
  • Metrics Wrapper

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-securitySecurity
Codepfad: versions/v04-security-observability-deep-dive/order-security

V04 Order Security

Kurzbeschreibung

Modultyp: Security Boundary

Zeigt Zugriffskontrolle, Approval Policies und Security Proxy rund um fachliche Services.

Was macht das Modul?

  • stellt SecurityContext bereit
  • definiert ApprovalPolicy und konkrete Policies
  • sichert Query Service ueber SecuredOrderQueryProxy

Ablauf im Gesamtsystem

  1. Client ruft Query/Approval an.
  2. Security Proxy prueft Context.
  3. ApprovalPolicy entscheidet nach Rolle/Risiko.

Wichtige Klassen und Dateien

  • SecurityContext
  • ApprovalPolicy
  • ManagerApprovalPolicy
  • RiskOfficerApprovalPolicy
  • SecuredOrderQueryProxy

Verwendete Entwurfsmuster

  • Proxy Pattern
  • Policy Pattern
  • Chain of Responsibility

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.

Testing 5

runnable-smokeTesting
Codepfad: versions/v01-modular-baseline/runnable-smoke

runnable-smoke

Dieses Modul macht den Workspace sofort ausfuehrbar.

Start

mvn -q -pl runnable-smoke -am package exec:java

Zweck

Der Smoke-Run fuehrt einen kompakten Enterprise-Ablauf aus: Order validieren, Inventory reservieren, Payment autorisieren, Outbox-Event erzeugen und Deployment-Bereitschaft pruefen.

Entwurfsmuster

  • Command: fachliche Schritte als ausfuehrbare Aktionen.
  • Pipeline: Schritte laufen in stabiler Reihenfolge.
  • Result Object: klare Rueckgabe ohne versteckte Seiteneffekte.
runnable-smokeTesting
Codepfad: versions/v02-clean-architecture-deep-dive/runnable-smoke

runnable-smoke

Dieses Modul macht den Workspace sofort ausfuehrbar.

Start

mvn -q -pl runnable-smoke -am package exec:java

Zweck

Der Smoke-Run fuehrt einen kompakten Enterprise-Ablauf aus: Order validieren, Inventory reservieren, Payment autorisieren, Outbox-Event erzeugen und Deployment-Bereitschaft pruefen.

Entwurfsmuster

  • Command: fachliche Schritte als ausfuehrbare Aktionen.
  • Pipeline: Schritte laufen in stabiler Reihenfolge.
  • Result Object: klare Rueckgabe ohne versteckte Seiteneffekte.
runnable-smokeTesting
Codepfad: versions/v03-event-driven-outbox-deep-dive/runnable-smoke

runnable-smoke

Dieses Modul macht den Workspace sofort ausfuehrbar.

Start

mvn -q -pl runnable-smoke -am package exec:java

Zweck

Der Smoke-Run fuehrt einen kompakten Enterprise-Ablauf aus: Order validieren, Inventory reservieren, Payment autorisieren, Outbox-Event erzeugen und Deployment-Bereitschaft pruefen.

Entwurfsmuster

  • Command: fachliche Schritte als ausfuehrbare Aktionen.
  • Pipeline: Schritte laufen in stabiler Reihenfolge.
  • Result Object: klare Rueckgabe ohne versteckte Seiteneffekte.
runnable-smokeTesting
Codepfad: versions/v04-security-observability-deep-dive/runnable-smoke

runnable-smoke

Dieses Modul macht den Workspace sofort ausfuehrbar.

Start

mvn -q -pl runnable-smoke -am package exec:java

Zweck

Der Smoke-Run fuehrt einen kompakten Enterprise-Ablauf aus: Order validieren, Inventory reservieren, Payment autorisieren, Outbox-Event erzeugen und Deployment-Bereitschaft pruefen.

Entwurfsmuster

  • Command: fachliche Schritte als ausfuehrbare Aktionen.
  • Pipeline: Schritte laufen in stabiler Reihenfolge.
  • Result Object: klare Rueckgabe ohne versteckte Seiteneffekte.
runnable-smokeTesting
Codepfad: versions/v05-cloud-native-ops-deep-dive/runnable-smoke

runnable-smoke

Dieses Modul macht den Workspace sofort ausfuehrbar.

Start

mvn -q -pl runnable-smoke -am package exec:java

Zweck

Der Smoke-Run fuehrt einen kompakten Enterprise-Ablauf aus: Order validieren, Inventory reservieren, Payment autorisieren, Outbox-Event erzeugen und Deployment-Bereitschaft pruefen.

Entwurfsmuster

  • Command: fachliche Schritte als ausfuehrbare Aktionen.
  • Pipeline: Schritte laufen in stabiler Reihenfolge.
  • Result Object: klare Rueckgabe ohne versteckte Seiteneffekte.

Weitere Module 7

v01-modular-baselineWeitere Module
Codepfad: versions/v01-modular-baseline

v01-modular-baseline-parent

Eigener Maven-Multi-Module-Workspace.

Start

cd versions/v01-modular-baseline
mvn test
mvn package

Modulrichtung

adapters / app -> application -> domain

Muster sind im Code mit // PATTERN: kommentiert und zentral in ../../docs/design-patterns.md dokumentiert.

Projektbeschreibung und Modulablauf

Diese Version enthaelt jetzt eine direkte Ablaufbeschreibung:

  • PROJECTS.md / PROJECTS.html: Gesamtuebersicht der Module dieser Version.
  • Jedes Maven-Modul besitzt ein eigenes README.md und README.html mit Zweck, Ablauf, wichtigen Klassen und Entwurfsmustern.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-appWeitere Module
Codepfad: versions/v01-modular-baseline/order-app

V01 Order App

Kurzbeschreibung

Modultyp: Bootstrap / Inbound Adapter

Startet die einfache Anwendung und stellt einen REST-nahen Einstieg in den Bestellprozess dar.

Was macht das Modul?

  • enthaelt V01Application als Startpunkt
  • enthaelt OrderController als Eingangsadapter
  • verdrahtet Application und Adapter didaktisch einfach

Ablauf im Gesamtsystem

  1. HTTP/Controller-Aufruf kommt herein.
  2. Controller baut ein Command.
  3. Use Case verarbeitet und speichert ueber den Adapter.

Wichtige Klassen und Dateien

  • V01Application
  • OrderController

Verwendete Entwurfsmuster

  • Controller
  • Composition Root
  • Dependency Injection

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
v02-clean-architecture-deep-diveWeitere Module
Codepfad: versions/v02-clean-architecture-deep-dive

v02-clean-architecture-parent

Eigener Maven-Multi-Module-Workspace.

Start

cd versions/v02-clean-architecture-deep-dive
mvn test
mvn package

Modulrichtung

adapters / app -> application -> domain

Muster sind im Code mit // PATTERN: kommentiert und zentral in ../../docs/design-patterns.md dokumentiert.

Projektbeschreibung und Modulablauf

Diese Version enthaelt jetzt eine direkte Ablaufbeschreibung:

  • PROJECTS.md / PROJECTS.html: Gesamtuebersicht der Module dieser Version.
  • Jedes Maven-Modul besitzt ein eigenes README.md und README.html mit Zweck, Ablauf, wichtigen Klassen und Entwurfsmustern.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-bootstrapWeitere Module
Codepfad: versions/v02-clean-architecture-deep-dive/order-bootstrap

V02 Order Bootstrap

Kurzbeschreibung

Modultyp: Runtime Composition

Verdrahtet Clean-Architecture-Bausteine in einer lauffaehigen Startkonfiguration.

Was macht das Modul?

  • enthaelt Startklasse V02Application
  • zeigt Composition Root fuer V02
  • haelt technische Verdrahtung ausserhalb der Domain

Ablauf im Gesamtsystem

  1. Application startet.
  2. Bootstrap erzeugt/verdrahtet Use Cases und Adapter.
  3. Requests laufen durch Controller, Use Case und Repository.

Wichtige Klassen und Dateien

  • V02Application

Verwendete Entwurfsmuster

  • Composition Root
  • Dependency Injection

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
v05-cloud-native-ops-deep-diveWeitere Module
Codepfad: versions/v05-cloud-native-ops-deep-dive

v05-cloud-native-ops-parent

Eigener Maven-Multi-Module-Workspace.

Start

cd versions/v05-cloud-native-ops-deep-dive
mvn test
mvn package

Modulrichtung

adapters / app -> application -> domain

Muster sind im Code mit // PATTERN: kommentiert und zentral in ../../docs/design-patterns.md dokumentiert.

Projektbeschreibung und Modulablauf

Diese Version enthaelt jetzt eine direkte Ablaufbeschreibung:

  • PROJECTS.md / PROJECTS.html: Gesamtuebersicht der Module dieser Version.
  • Jedes Maven-Modul besitzt ein eigenes README.md und README.html mit Zweck, Ablauf, wichtigen Klassen und Entwurfsmustern.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-commandWeitere Module
Codepfad: versions/v05-cloud-native-ops-deep-dive/order-command

V05 Order Command

Kurzbeschreibung

Modultyp: Command/CQRS Write Side

Enthaelt die schreibende Seite fuer Bestellungen mit Command Handler und SubmitOrderCommand.

Was macht das Modul?

  • definiert SubmitOrderCommand
  • verarbeitet Commands im OrderCommandHandler
  • trennt Schreibmodell vom Lesemodell

Ablauf im Gesamtsystem

  1. API erzeugt SubmitOrderCommand.
  2. Command Handler validiert und verarbeitet.
  3. Integration/Saga kann nachgelagert reagieren.

Wichtige Klassen und Dateien

  • SubmitOrderCommand
  • OrderCommandHandler

Verwendete Entwurfsmuster

  • CQRS
  • Command Handler
  • Command Pattern

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Stand 2026-07-07. Relative Links lokal nutzbar.
order-queryWeitere Module
Codepfad: versions/v05-cloud-native-ops-deep-dive/order-query

V05 Order Query

Kurzbeschreibung

Modultyp: CQRS Read Side

Zeigt ein separates Lesemodell und Query Handler fuer schnelle fachliche Abfragen.

Was macht das Modul?

  • definiert OrderReadModel
  • stellt OrderQueryHandler bereit
  • trennt Lesen von Schreiben

Ablauf im Gesamtsystem

  1. API fragt Query Handler.
  2. Read Model liefert optimierte Sicht.
  3. Schreibmodell bleibt unabhaengig.

Wichtige Klassen und Dateien

  • OrderReadModel
  • OrderQueryHandler

Verwendete Entwurfsmuster

  • CQRS
  • Read Model
  • Query Handler

Typischer Einstieg beim Lesen

  1. Zuerst dieses README lesen.
  2. Dann pom.xml ansehen.
  3. Danach die genannten Klassen oeffnen.
  4. Am Ende ../../../docs/design-patterns.md lesen und die // PATTERN:-Marker im Code vergleichen.
Projektübersicht · Aydin Modern Enterprise Maven Master

Aydin Modern Enterprise Maven Master

Dieses Paket ist ein neuer Master-Workspace für moderne Enterprise-Java- und Maven-Modularisierung.

Es ist bewusst als Lern- und Referenzpaket aufgebaut: jede Version vertieft Architektur, Code, Tests, Infrastruktur und Entwurfsmuster.

Inhalt

BereichZweck
versions/v01-modular-baselineMaven Multi-Module, Domain/Application/Adapter-Aufteilung, einfacher Spring-Boot-Startpunkt
versions/v02-clean-architecture-deep-divePorts & Adapters, Use Cases, Mapper, Testgrenzen, API-Schicht
versions/v03-event-driven-outbox-deep-diveDomain Events, Outbox, Idempotenz, Publish-Workflow
versions/v04-security-observability-deep-diveSecurity Boundary, Audit, Metrics, Decorator/Chain/Proxy
versions/v05-cloud-native-ops-deep-diveCloud-Native Betrieb, OpenShift/Kubernetes, CQRS, Saga, Resilience
docs/design-patterns.mdzentrale Pattern-Dokumentation mit Zweck, Einsatzort und Begründung
docs/architecture.mdArchitekturüberblick, Modulregeln, Kommunikationsregeln
docs/deep-dive-roadmap.mdempfohlene Lernreihenfolge und Erweiterungsplan
html/desktop/index.htmlDesktop-Leseversion mit modernen Karten und Codeblöcken
html/iphone-safari/index.htmliPhone-/Safari-taugliche Leseversion ohne Pflicht-JavaScript
prompts/Prompts für nächste Ausbauphasen
reports/Prüfberichte, Linkprüfung, Lizenzhinweise

Öffnen

1. ZIP entpacken.

2. index.html im Root öffnen.

3. Danach entweder in die HTML-Leseversion oder direkt in versions/... wechseln.

4. Für Maven pro Version in den jeweiligen Versionsordner wechseln und mvn test oder mvn package ausführen.

Maven-Hinweis

Jede Version ist ein eigener Maven-Multi-Module-Workspace. Dadurch kann man Versionen unabhängig betrachten, vergleichen und vertiefen.

Die Projekte sind didaktisch aufgebaut: nicht jede Infrastruktur-Komponente verbindet sich mit einem echten Server, aber jede Schicht zeigt bewusst Enterprise-Struktur, Schnittstellen und Erweiterungspunkte.

Entwurfsmuster-Regel

Verwendete Muster sind an zwei Stellen markiert:

  • direkt im Java-Code mit Kommentaren wie // PATTERN: Repository
  • zentral in docs/design-patterns.md

Stand: 2026-07-07

Runnable Smoke-Test

Siehe RUNNABLE.md und RUNNABLE.html. Jeder Workspace enthaelt ein Modul runnable-smoke mit Startskripten.

Start und Runtime · Master 1 runnable machen

Master 1 runnable machen

<span class="ok">Runnable-Ergaenzung</span>

Dieser Master enthaelt jetzt ein eigenes Maven-Modul runnable-smoke. Damit ist nicht nur Dokumentation vorhanden, sondern ein direkt ausfuehrbarer fachlicher Ablauf.

Startbefehle

  • versions/v01-modular-baseline: cd versions/v01-modular-baseline && mvn -q -pl runnable-smoke -am package exec:java
  • versions/v02-clean-architecture-deep-dive: cd versions/v02-clean-architecture-deep-dive && mvn -q -pl runnable-smoke -am package exec:java
  • versions/v03-event-driven-outbox-deep-dive: cd versions/v03-event-driven-outbox-deep-dive && mvn -q -pl runnable-smoke -am package exec:java
  • versions/v04-security-observability-deep-dive: cd versions/v04-security-observability-deep-dive && mvn -q -pl runnable-smoke -am package exec:java
  • versions/v05-cloud-native-ops-deep-dive: cd versions/v05-cloud-native-ops-deep-dive && mvn -q -pl runnable-smoke -am package exec:java

Was der Smoke-Run tut

Der Ablauf simuliert eine echte Enterprise-Kette:

  • Bestellung validieren
  • Bestand reservieren
  • Zahlung autorisieren
  • Outbox-Event erzeugen
  • Deployment-Bereitschaft pruefen

Warum Smoke-Runner und nicht alle externen Systeme starten?

AWS, OpenShift, IBM MQ, Oracle, SFTP, Spring/Jakarta Runtime und Bare-Metal-Adapter brauchen reale Infrastruktur oder Container. Der Smoke-Runner ist bewusst lokal und ohne externe Infrastruktur startbar. Die produktnahen Module bleiben Maven-Module mit POMs, Beschreibungen und Pattern-Kommentaren; der Smoke-Runner ist der schnelle Nachweis, dass der Workspace ausfuehrbar ist.

Empfohlene Reihenfolge

1. mvn -q -pl runnable-smoke -am package exec:java

2. Danach gesamtes Projekt bauen: mvn clean package

3. Dann einzelne Runtime-Module starten, z. B. Spring Boot oder OpenShift-Deployment.

⌂ Cockpit