Master 2.1

Project Descriptions

Projektbeschreibungen, Ablauf und Modulzweck wurden direkt in den Maven-Workspace integriert.

Projektbeschreibungen und Ablauf

Dieses Dokument beschreibt kurz, was jedes Maven-Modul tut und wie der fachliche Ablauf durch die Module laeuft. Die gleichen Beschreibungen sind zusaetzlich direkt in den einzelnen Modulordnern als README.md und README.html integriert.

Fachlicher End-to-End-Ablauf

  1. HTTP Eingang: adapters-rest-spring oder app-quarkus nimmt eine Bestellung entgegen.
  2. Command: Der Eingang wird in PlaceOrderCommand uebersetzt.
  3. Use Case: order-application orchestriert Kreditpruefung, Lagerpruefung, Preislogik, Bestellung und Transaktionsgrenze.
  4. Domain: order-domain erzwingt Invarianten und erzeugt OrderPlaced.
  5. Persistenz: adapters-persistence-jpa speichert Bestellung und technische Transaktion.
  6. Outbox: integration-outbox speichert Event-Auslieferungsabsicht und liefert spaeter aus.
  7. Messaging: adapters-messaging-kafka publiziert Events und schuetzt Konsumenten mit Idempotenz.
  8. Legacy: adapters-legacy-acl kapselt altes SOAP-/Legacy-Modell.
  9. Runtime: app-spring-boot oder app-quarkus startet die gewuenschte Laufzeit.
  10. Qualitaet: architecture-tests prueft Modulgrenzen, Pattern-Marker und Architekturregeln.

Moduluebersicht

Modul Typ Was es tut Ablaufrolle
platform-bom Maven-BOM / Build Governance Zentralisiert Versionsverwaltung und gemeinsame Test-/Architektur-Bibliotheken, damit alle Module reproduzierbar dieselben Dependency-Versionen verwenden. Wird zuerst im Reactor gelesen.; Andere Module importieren oder verwenden die verwalteten Versionen indirekt ueber den Parent.
shared-kernel Domain Foundation Enthaelt kleine, stabile Bausteine, die mehrere fachliche Bounded Contexts gemeinsam benutzen duerfen. Domain-Module haengen von shared-kernel ab.; Aggregate registrieren Domain Events.
order-domain Kern-Domain Modelliert Bestellung, Bestellpositionen, Status, Repository-Port und fachliche Spezifikationen. PlaceOrderService erstellt Order aus Command-Daten.; Order prueft Invarianten und registriert Domain Events.
customer-domain Bounded Context Kapselt Kundenregeln, besonders Kredit- und Freigabeentscheidungen fuer Bestellungen. Order Application fragt Credit Policy vor dem Platzieren.; Policy entscheidet anhand Kundendaten und Risiko.
inventory-domain Bounded Context Beschreibt Reservierungsregeln fuer Lagerbestand, ohne direkt von Datenbank oder Messaging abzuhaengen. Order Application prueft Reservierbarkeit.; Inventory Policy bewertet Positionen.
pricing-domain Bounded Context Berechnet Preise ueber austauschbare Strategien, damit Rabatt-, Staffel- oder Kampagnenlogik nicht im Order Aggregate landet. Use Case uebergibt Warenkorb oder Positionen an Pricing Strategy.; Strategie berechnet Money-Werte.
payment-domain Bounded Context / Port Definiert die Zahlungsintegration als Port, damit echte Provider, Mocks oder Legacy-Zahlungssysteme austauschbar bleiben. PaymentSaga oder Application ruft PaymentGatewayPort.; Ein Adapter fuehrt die echte Zahlung aus.
fulfillment-domain Bounded Context Plant Versand- oder Erfuellungsaktivitaeten nach erfolgreicher Bestellung und Zahlung. Nach erfolgreicher Zahlung startet Fulfillment-Planung.; FulfillmentPlanner erzeugt naechste Schritte.
notification-domain Bounded Context Kapselt Benachrichtigungsvorlagen und die fachliche Entscheidung, welche Nachricht wann versendet werden soll. Ein Event wie OrderPlaced loest Benachrichtigung aus.; Template erzeugt fachlichen Inhalt.
order-application Use-Case-Schicht Orchestriert den fachlichen Bestellablauf zwischen Domain-Modulen, Ports, Transaktionen und Ergebnisobjekten. REST oder Quarkus Resource sendet PlaceOrderCommand.; PlaceOrderService prueft Regeln und erzeugt Order.
integration-outbox Integration / Reliability Macht Event-Publishing robust, indem fachliche Aenderung und Event-Auslieferungsabsicht getrennt aber nachvollziehbar behandelt werden. Domain erzeugt Event.; Application speichert Aggregate und OutboxRecord in einer Transaktion.
adapters-rest-spring Inbound Adapter Stellt HTTP-Endpunkte bereit und uebersetzt Web-Requests in Use-Case-Commands. Client sendet HTTP Request.; OrderRestController validiert und baut Command.
adapters-persistence-jpa Outbound Adapter Implementiert Persistenz fuer Orders und Outbox, ohne JPA in die Domain eindringen zu lassen. Application ruft OrderRepository.; JpaOrderRepositoryAdapter mappt Domain auf Entity.
adapters-messaging-kafka Outbound Messaging Adapter Publiziert Integrationsereignisse nach Kafka und schuetzt Konsumenten gegen doppelte Verarbeitung. OutboxRelay liefert Record an Publisher.; KafkaEventPublisher sendet Nachricht.
adapters-legacy-acl Legacy Integration Schuetzt moderne Domain vor altem SOAP-/Legacy-Modell durch eine Anti-Corruption-Layer. Application braucht Legacy-Daten.; LegacyOrderGateway ruft SOAP Client.
app-spring-boot Runtime Composition Startet die Spring-Boot-Variante und verdrahtet REST, Persistenz, Messaging, Security und Observability. Spring Boot startet Application Context.; UseCaseConfiguration verbindet Ports mit Adaptern.
app-quarkus Alternative Runtime Zeigt dieselben Use Cases in einer Quarkus/Jakarta-Runtime, um Framework-Austauschbarkeit der Architektur zu demonstrieren. Quarkus startet Resource.; InMemoryQuarkusWiring liefert Use-Case-Instanzen.
architecture-tests Qualitaets-Gate Prueft Architekturregeln automatisiert, damit Modulgrenzen und Pattern-Markierungen nicht nur Dokumentation bleiben. Maven test/verify fuehrt Architecture Tests aus.; LayerRulesTest prueft Abhaengigkeitsrichtung.

Lese-Reihenfolge

  1. shared-kernel fuer Grundtypen.
  2. order-domain fuer fachlichen Kern.
  3. order-application fuer Use-Case-Ablauf.
  4. adapters-rest-spring und adapters-persistence-jpa fuer technische Umsetzung.
  5. integration-outbox und adapters-messaging-kafka fuer robuste Events.
  6. app-spring-boot oder app-quarkus fuer Laufzeit.
  7. architecture-tests fuer automatische Regeln.

Entwurfsmuster im Ablauf

  • Aggregate Root: Order schuetzt Konsistenz.
  • Command Pattern: PlaceOrderCommand transportiert den Wunsch, eine Bestellung anzulegen.
  • Application Service: PlaceOrderService orchestriert, aber enthaelt keine Infrastrukturdetails.
  • Ports and Adapters: Use Cases kennen nur Ports; Adapter implementieren Technik.
  • Transactional Outbox: Domain-Aenderung und Event-Auslieferung werden robust gekoppelt.
  • Saga: Mehrschrittiger Zahlungs-/Fulfillment-Prozess wird explizit koordiniert.
  • Anti-Corruption Layer: Legacy-Modelle bleiben ausserhalb der modernen Domain.
  • Architecture Fitness Function: ArchUnit schuetzt Regeln im Build.

Stand 2026-07-07. Markdown und HTML synchron erzeugt.

⌂ Cockpit