Domain-Driven Design – vollständiges Architekturwerk

Fachliche Erkundung

Zweck dieses Kapitels

beginnt die DDD-Variante bewusst im Problemraum. Es werden noch keine Bounded Contexts, Aggregate oder technischen Module festgelegt. Zuerst wird geklärt, welche geschäftlichen Entscheidungen das Order-to-Cash-System treffen muss, wer von ihnen betroffen ist und wo Unsicherheit oder Konflikt entsteht.

Verbindliche Leitplanken

• Die gemeinsame Referenzfachlichkeit aus den der gemeinsamen Referenzspezifikation bleibt unverändert.
• Die Layered- und TDD-Implementierungen sind Vergleichsobjekte, aber keine Vorlage für das DDD-Modell.
• Technische Begriffe dürfen eine fachliche Grenze nicht vorwegnehmen.
• Ein Prozessschritt ist noch kein Bounded Context.
• Ein vorhandenes Datenbankobjekt ist noch kein Aggregate.
• Jede Hypothese bleibt als Hypothese markiert, bis Sprache, Datenhoheit und Konsistenz sie stützen.

Geschäftliches Zielbild

Die Plattform soll einen Kundenwunsch in eine nachvollziehbare und belastbare Zusage überführen. Sie muss gleichzeitig verhindern, dass nicht verfügbare Ware zugesagt, ein Kunde doppelt belastet, ein unpassender Beleg erzeugt oder ein nicht versandfähiger Auftrag unbemerkt fortgeführt wird.

End-to-End-Erkundung

1. Ein Kunde und ein verkaufsfähiges Angebot bilden die Voraussetzung für eine Bestellzusage.
2. Die Bestellzusage friert die für den Auftrag relevanten Produkt- und Preisinformationen ein.
3. Die Bestandszusage muss vollständig und atomar sein; eine stille Teilzusage ist nicht erlaubt.
4. Die Zahlungsentscheidung unterscheidet fachliche Ablehnung von technischer Unsicherheit.
5. Die Rechnung belegt einen bereits erreichten fachlichen Zustand und darf ihn nicht neu interpretieren.
6. Die Auslieferung benötigt eine eigene Übergabeentscheidung und kann eine Kompensation auslösen.
7. Kommunikation und Audit beobachten den Prozess, dürfen seine fachliche Hoheit aber nicht übernehmen.

Zentrale Entdeckungsfragen

• Was bedeutet eine verbindliche Bestellung für Vertrieb, Lager und Finance jeweils?
• Wer besitzt die Wahrheit über Verkaufsfähigkeit, Verfügbarkeit, Zahlungsstatus und Versandfähigkeit?
• Welche Entscheidungen müssen sofort konsistent sein und welche dürfen zeitversetzt fortgeführt werden?
• Welche Fehler sind fachliche Ergebnisse und welche sind technische Störungen?
• Welche Begriffe ändern ihre Bedeutung entlang des Prozesses?
• Wo entstehen Konflikte zwischen Kundenerwartung, operativer Realität und Compliance?

Ergebnisgrenze

liefert eine belastbare Discovery-Basis. Die gemeinsame Fachsprache wird erst im entsprechenden Kapitel konsolidiert, die strategische Einordnung der Subdomains erst im entsprechenden Kapitel und die Bounded Contexts erst im entsprechenden Kapitel festgelegt.

Stakeholder und gewünschte Ergebnisse

Stakeholder-Landkarte

Gemeinsame Zielkonflikte

Geschwindigkeit gegen Entscheidungssicherheit

Vertrieb und Kunde wünschen schnelle Zusage. Lager, Payment und Compliance benötigen belastbare Prüfungen. DDD muss diese Spannung als fachliche Entscheidung sichtbar machen, statt sie in einem technischen Workflow zu verstecken.

Lokale Optimierung gegen Ende-zu-Ende-Verantwortung

Jeder Bereich kann seinen Schritt lokal erfolgreich abschließen, während der Gesamtprozess dennoch blockiert bleibt. Darum werden lokale Ergebnisse und der übergreifende Prozessstatus getrennt betrachtet.

Automatisierung gegen erklärbare Eingriffe

Der Normalfall soll automatisiert sein. Customer Service und Betrieb benötigen dennoch nachvollziehbare Gründe, Wiederholungsmöglichkeiten und klare Grenzen für manuelle Eingriffe.

Erfolgsindikatoren für die spätere Architektur

• fachliche Ablehnungen sind benannt und nicht als generische technische Fehler versteckt
• jede Zusage besitzt eine klar benannte verantwortliche Fähigkeit
• wiederholte Anfragen erzeugen keine zweite fachliche Wirkung
• Prozessstatus kann ohne Zugriff auf interne Tabellen erklärt werden
• lokale Modelle teilen nur ausdrücklich vereinbarte Begriffe

Fachliche Fähigkeiten

Abgrenzung

Die folgenden Fähigkeiten beschreiben, was das Unternehmen zuverlässig können muss. Sie sind noch keine Module und noch keine endgültigen Subdomains. Ihre strategische Einordnung folgt im nächsten Kapitel.

Fähigkeitenübersicht

Abhängigkeiten als fachliche Aussagen

• Bestellzusage benötigt Kundenberechtigung und ein verkaufsfähiges Angebot.
• Verfügbarkeitszusage benötigt eine angenommene Bestellung, besitzt aber ihre eigene Bestandswahrheit.
• Zahlungsabsicherung benötigt den offenen Auftragsbetrag, entscheidet aber unabhängig über Providerreaktionen.
• Rechnungsbeleg benötigt einen final autorisierten Zahlungsstand.
• Auslieferung benötigt Rechnungs- und Reservierungsnachweis, entscheidet jedoch selbst über Übergabefähigkeit.
• Kommunikation reagiert auf Ergebnisse; sie erzeugt keine Bestell-, Zahlungs- oder Versandentscheidung.

Noch offene strategische Fragen

• Welche Fähigkeit trägt den größten differenzierenden Geschäftswert?
• Welche Fähigkeiten können standardisiert oder eingekauft werden?
• Wo ist die Änderungsrate so hoch, dass ein eigenes Modell unverzichtbar ist?
• Welche Fähigkeiten benötigen getrennte Teams und getrennte Datenhoheit?

Problemräume und Hotspots

Verkaufszusage

Leitfrage Wann wird aus einem Kundenwunsch eine verbindliche Bestellung?

Hotspots

• aktiver Kunde und zulässige Geschäftsbeziehung
• verkaufsfähiges Produkt zum gespeicherten Preis
• unveränderlicher Snapshot statt späterer Kataloginterpretation
• konfliktfeste Wiederholung derselben Anfrage
• klare Grenze zwischen Entwurf, Annahme und Storno

Bestandszusage

Leitfrage Wie wird eine vollständige Zusage ohne Teilreservierung und Überverkauf garantiert?

Hotspots

• Gesamtprüfung aller Positionen vor Mutation
• parallele Reservierungsversuche
• Freigabe und erneute Verfügbarkeit
• physischer Bestand, reservierte Menge und verfügbare Menge
• Datenalter und Verantwortung für Bestandswahrheit

Zahlungsentscheidung

Leitfrage Welche Ergebnisse sind fachlich final, welche technisch unsicher und wiederholbar?

Hotspots

• exakte Übereinstimmung von offenem Betrag und Zahlungsauftrag
• fachliche Ablehnung ohne automatischen Retry
• technische Nichtverfügbarkeit mit begrenztem Retry
• stabile Idempotenz über Provideraufrufe hinweg
• Abstimmung von Autorisierung, Auftrag und späterem Beleg

Beleg und Auslieferung

Leitfrage Wann ist ein Auftrag beleg- und versandfähig?

Hotspots

• unveränderlicher Rechnungsstand
• eindeutige Rechnungsnummer
• Adressprüfung und dauerhafte Ablehnung
• Tracking und Übergabe an Logistik
• Kompensation bei nicht erfüllbarer Auslieferung

Prozesssicht

Leitfrage Wie bleibt ein verteilter Ablauf fachlich erklärbar?

Hotspots

• gemeinsame Korrelation ohne gemeinsames Gesamtmodell
• lokale Zustände gegenüber Ende-zu-Ende-Sicht
• verzögerte oder doppelte Ereigniszustellung
• Nachweis von Ursache, Entscheidung und Wirkung
• manuelle Intervention ohne Umgehung fachlicher Regeln

Risiko zu früher Lösungssprache

Begriffe wie Service, Entity, Queue, Tabelle oder Transaktion dürfen in der Discovery nicht als fachliche Grenze verwendet werden. Zuerst wird geklärt, welche Entscheidung geschützt werden muss; erst danach folgt die technische Form.

Discovery-Workshop

Arbeitsform

Der Workshop betrachtet den Geschäftsprozess als Folge von Auslösern, Entscheidungen und beobachtbaren Ergebnissen. Die Begriffe sind vorläufig. prüft sie gemeinsam auf Eindeutigkeit und lokale Bedeutung.

Prozesskette

Kandidaten für Fachereignisse

• CustomerRegistered
• ProductRegistered
• OrderPlaced
• InventoryReserved
• InventoryReservationReleased
• PaymentAuthorized
• PaymentDeclined
• PaymentDeferred
• InvoiceIssued
• ShipmentPrepared
• ShipmentPreparationDeferred
• CompensationRequested

Diese Namen sind noch keine endgültige Published Language. Sie dienen als Diskussionsanker und werden im entsprechenden Kapitel sprachlich konsolidiert.

Policies und Reaktionen

• Nach angenommener Bestellung soll eine Verfügbarkeitsentscheidung angestoßen werden.
• Nach vollständiger Reservierung soll die Zahlung abgesichert werden.
• Nach finaler Zahlungsautorisierung soll eine Rechnung entstehen.
• Nach Rechnungsstellung soll die Auslieferung vorbereitet werden.
• Nach dauerhafter Versandablehnung soll ein Kompensationsfall entstehen.
• Benachrichtigungen reagieren auf Fachereignisse und entscheiden den Hauptprozess nicht.

Read-Model-Bedarf

• Customer Service benötigt eine Ende-zu-Ende-Fallsicht.
• Kunde benötigt einen verständlichen Auftragsstatus.
• Lager benötigt offene und freizugebende Reservierungen.
• Finance benötigt Abstimmung zwischen Zahlung und Beleg.
• Betrieb benötigt verzögerte, wiederholte und blockierte Prozessschritte.

Hotspot-Fragen für die nächsten Fachkapitel

• Ist „Order“ in Vertrieb, Finance und Fulfillment wirklich derselbe Begriff?
• Ist eine Reservierung Teil der Bestellung oder eine eigenständige Zusage?
• Ist Payment eine eigene Fachdomäne oder primär eine Anti-Corruption-Grenze zum Provider?
• Wer darf einen blockierten Auftrag fortsetzen oder kompensieren?

Offene Fragen und Hypothesen

Arbeitsregel

Hypothesen werden nicht stillschweigend zu Architekturentscheidungen. Jede Aussage besitzt einen Status und einen geplanten Validierungsschritt.

Hypothesenregister

Offene Fachfragen

• Kann eine Bestellung vor Bestandszusage bereits verbindlich sein?
• Wann darf eine Reservierung verfallen, und wer entscheidet darüber?
• Ist eine zurückgestellte Zahlung für den Kunden sichtbar oder nur ein interner Zustand?
• Welche rechtlichen Regeln bestimmen Rechnungszeitpunkt und Unveränderlichkeit?
• Welche Versandfehler sind wiederholbar und welche erfordern Kompensation?
• Welche manuellen Eingriffe benötigen Vier-Augen-Freigabe oder Auditpflicht?

Offene Organisationsfragen

• Welche Teams verantworten aktuell Angebot, Auftrag, Bestand, Payment, Billing und Fulfillment?
• Wo existieren bereits getrennte Datenhoheiten oder eigene Änderungszyklen?
• Welche externen Systeme geben fachliche Vorgaben vor?
• Welche Begriffe werden heute in verschiedenen Abteilungen unterschiedlich verwendet?

Rückverfolgbarkeit der Discovery

Bezug zur gemeinsamen Referenz

Die DDD-Erkundung verändert keine fachliche Anforderung. Sie ordnet die vorhandenen Use Cases, Regeln und Ereignisse nach Entscheidungen und Problemräumen neu ein.

Abdeckung

• alle zehn gemeinsamen Use Cases sind mindestens einem Discovery-Bereich zugeordnet
• alle geschäftskritischen Zusagen besitzen eine benannte Entscheidung
• technische Integrationsdetails bestimmen noch keine Kontextgrenze
• offene Mehrdeutigkeiten sind im Hypothesenregister sichtbar

Übergabe an

übernimmt Stakeholderbegriffe, Ereigniskandidaten, Hotspots und Hypothesen. Daraus wird eine kontrollierte Ubiquitous Language mit Definition, Gegenbegriff, Kontextabhängigkeit und verbotenen Synonymen aufgebaut.

Ubiquitous Language

Zweck

konsolidiert die Fachsprache der DDD-Variante. Die Sprache beschreibt Entscheidungen, Zustände und Ergebnisse so präzise, dass Fachseite, Tests, Schnittstellen und spätere Modellierung dieselben Bedeutungen verwenden können.

Verbindliche Ergebnisse

• 50 kanonische Fachbegriffe mit stabilen Kennungen
• 14 aufgelöste semantische Konflikte
• 12 verbindliche Sprachregeln
• fünf realistische Gesprächsszenarien
• Lebenszyklus für vorgeschlagene, akzeptierte, lokale und veraltete Begriffe
• Rückverfolgbarkeit zu allen zehn gemeinsamen Use Cases

Leitplanken

• Die Sprache entsteht aus dem Problemraum und nicht aus vorhandenen Klassen oder Tabellen.
• Lokale Bedeutungen werden sichtbar markiert und nicht zu einer künstlichen globalen Definition vereinheitlicht.
• Noch werden keine Bounded Contexts oder Aggregate festgelegt.
• Fachfehler und technische Störungen bleiben sprachlich getrennt.
• Bestell-, Bestands-, Zahlungs-, Rechnungs- und Versandzustände werden nicht in einem globalen Statusbegriff vermischt.

Ergebnisgrenze

liefert eine belastbare Sprache für die strategische Einordnung im entsprechenden Kapitel. Die Begriffe dürfen Hypothesen über spätere Grenzen unterstützen, legen sie aber noch nicht fest.

Kanonischer Begriffskatalog

Der Katalog enthält 50 Begriffe. Jede Definition besitzt eine stabile Kennung, eine fachliche Perspektive, kontrollierte Synonyme, unzulässige Alternativen, einen Lebenszyklus und Use-Case-Bezüge.

UL-001 – Kunde

Person oder Organisation, für die eine aktive und zulässige Geschäftsbeziehung besteht.

• Perspektive: Vertrieb
• Zugelassene Synonyme: Kunde, Käufer
• Nicht verwenden: Account, User
• Status: accepted
• Use Cases: UC-01, UC-03

UL-002 – Kundenkennung

Stabile fachliche Identität eines Kunden; sie bleibt unabhängig von E-Mail-Adresse oder Anzeigename.

• Perspektive: Vertrieb
• Zugelassene Synonyme: Kunden-ID
• Nicht verwenden: Datenbankschlüssel
• Status: accepted
• Use Cases: UC-01, UC-03

UL-003 – aktive Kundenbeziehung

Zustand, in dem ein Kunde Bestellungen verbindlich abgeben darf.

• Perspektive: Vertrieb
• Zugelassene Synonyme: aktiver Kunde
• Nicht verwenden: freigeschaltetes Login
• Status: accepted
• Use Cases: UC-01, UC-03

UL-004 – Produkt

Verwaltetes Verkaufsobjekt mit Identität, Name, Preis und Verkaufsstatus.

• Perspektive: Angebot
• Zugelassene Synonyme: Artikel
• Nicht verwenden: Datensatz
• Status: accepted
• Use Cases: UC-02, UC-03

UL-005 – Artikelnummer

Eindeutige, normalisierte fachliche Kennung eines Produkts.

• Perspektive: Angebot
• Zugelassene Synonyme: SKU
• Nicht verwenden: technische ID
• Status: accepted
• Use Cases: UC-02, UC-03

UL-006 – verkaufsfähig

Produktzustand, der das Aufnehmen in eine neue Bestellung erlaubt.

• Perspektive: Angebot
• Zugelassene Synonyme: aktiv, bestellbar
• Nicht verwenden: vorhanden
• Status: accepted
• Use Cases: UC-02, UC-03

UL-007 – Verkaufspreis

Aktuell angebotener Geldbetrag eines Produkts vor dem Einfrieren in einer Bestellung.

• Perspektive: Angebot
• Zugelassene Synonyme: Preis
• Nicht verwenden: Betrag
• Status: accepted
• Use Cases: UC-02, UC-03

UL-008 – Preis-Snapshot

Unveränderlicher Preis, der bei der Bestellzusage in einer Bestellposition festgehalten wird.

• Perspektive: Bestellung
• Zugelassene Synonyme: eingefrorener Preis
• Nicht verwenden: aktueller Produktpreis
• Status: accepted
• Use Cases: UC-03, UC-06

UL-009 – Bestellentwurf

Veränderbare Zusammenstellung gewünschter Positionen vor der verbindlichen Zusage.

• Perspektive: Bestellung
• Zugelassene Synonyme: Warenkorb, Entwurf
• Nicht verwenden: Bestellung
• Status: accepted
• Use Cases: UC-03

UL-010 – Bestellung

Fachlicher Auftrag mit stabiler Identität und explizitem Zustand; ohne Zustandswort darf der Begriff nicht als zugesagt verstanden werden.

• Perspektive: Bestellung
• Zugelassene Synonyme: Auftrag
• Nicht verwenden: Warenkorb
• Status: local
• Use Cases: UC-03, UC-09

UL-011 – Bestellposition

Unveränderliche Kombination aus Produkt-Snapshot, positiver Menge und Preis-Snapshot innerhalb einer zugesagten Bestellung.

• Perspektive: Bestellung
• Zugelassene Synonyme: Position
• Nicht verwenden: Produktzeile
• Status: accepted
• Use Cases: UC-03, UC-06

UL-012 – Bestellzusage

Erfolgreiche fachliche Entscheidung, dass eine Bestellung mit ihren Snapshots angenommen wurde.

• Perspektive: Bestellung
• Zugelassene Synonyme: Bestellung aufgegeben
• Nicht verwenden: Request gespeichert
• Status: accepted
• Use Cases: UC-03

UL-013 – Idempotenzschlüssel

Vom Aufrufer bereitgestellte fachliche Wiederholungskennung für denselben beabsichtigten Auftrag.

• Perspektive: Querschnitt
• Zugelassene Synonyme: Idempotency Key
• Nicht verwenden: Request-ID
• Status: accepted
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07

UL-014 – Korrelationskennung

Kennung zur Nachverfolgung eines fachlichen Ablaufs über mehrere Schritte und Nachrichten.

• Perspektive: Audit
• Zugelassene Synonyme: Correlation ID
• Nicht verwenden: Idempotenzschlüssel
• Status: accepted
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07, UC-08

UL-015 – Bestandsposition

Fachlich geführte Menge eines Produkts, aus der Verfügbarkeit und Reservierungen abgeleitet werden.

• Perspektive: Bestand
• Zugelassene Synonyme: Lagerbestand
• Nicht verwenden: Produkt
• Status: accepted
• Use Cases: UC-04

UL-016 – verfügbarer Bestand

Menge, die nach bereits bestehenden Reservierungen noch verbindlich zugesagt werden kann.

• Perspektive: Bestand
• Zugelassene Synonyme: verfügbar
• Nicht verwenden: physisch vorhanden
• Status: accepted
• Use Cases: UC-04

UL-017 – Reservierungsanfrage

Auftrag, bestimmte Mengen für eine Bestellung zu prüfen und atomar zu sichern.

• Perspektive: Bestand
• Zugelassene Synonyme: Reserve Request
• Nicht verwenden: Reservierung
• Status: accepted
• Use Cases: UC-04

UL-018 – Bestandsreservierung

Erfolgreiche, vollständige und atomare Bestandszusage für eine konkrete Bestellung.

• Perspektive: Bestand
• Zugelassene Synonyme: Reservierung
• Nicht verwenden: Bestandsabfrage
• Status: accepted
• Use Cases: UC-04, UC-09

UL-019 – Reservierungsfreigabe

Fachliche Rücknahme einer bestehenden Bestandsreservierung, sodass die Menge wieder verfügbar wird.

• Perspektive: Bestand
• Zugelassene Synonyme: Release
• Nicht verwenden: Stornierung
• Status: accepted
• Use Cases: UC-09

UL-020 – vollständige Reservierung

Regel, dass entweder alle angeforderten Positionen reserviert werden oder keine.

• Perspektive: Bestand
• Zugelassene Synonyme: All-or-nothing
• Nicht verwenden: Teilreservierung
• Status: accepted
• Use Cases: UC-04

UL-021 – Zahlungsversuch

Ein fachlich identifizierbarer Versuch, eine Zahlung für eine Bestellung autorisieren zu lassen.

• Perspektive: Finance
• Zugelassene Synonyme: Payment Attempt
• Nicht verwenden: HTTP-Aufruf
• Status: accepted
• Use Cases: UC-05

UL-022 – Zahlungsautorisierung

Positive Entscheidung des Zahlungsanbieters, den Betrag für die Bestellung zu reservieren; sie ist noch keine endgültige Abbuchung.

• Perspektive: Finance
• Zugelassene Synonyme: autorisiert
• Nicht verwenden: bezahlt
• Status: accepted
• Use Cases: UC-05, UC-06

UL-023 – Zahlungsablehnung

Fachliches negatives Ergebnis eines Zahlungsversuchs, das nicht durch technische Wiederholung geändert werden soll.

• Perspektive: Finance
• Zugelassene Synonyme: declined
• Nicht verwenden: technischer Fehler
• Status: accepted
• Use Cases: UC-05, UC-10

UL-024 – Zahlungsunsicherheit

Zustand nach technischer Störung, in dem das externe Zahlungsergebnis noch nicht belastbar bekannt ist.

• Perspektive: Finance
• Zugelassene Synonyme: unklar, deferred
• Nicht verwenden: abgelehnt
• Status: accepted
• Use Cases: UC-05, UC-10

UL-025 – Zahlungsreferenz

Vom Zahlungsanbieter vergebene fachliche Referenz einer Autorisierung oder Ablehnung.

• Perspektive: Finance
• Zugelassene Synonyme: Provider-Referenz
• Nicht verwenden: Korrelationskennung
• Status: accepted
• Use Cases: UC-05

UL-026 – Wiederholungsversuch

Kontrollierte erneute technische Ausführung desselben Zahlungsauftrags mit stabiler fachlicher Identität.

• Perspektive: Finance
• Zugelassene Synonyme: Retry
• Nicht verwenden: neue Zahlung
• Status: accepted
• Use Cases: UC-05, UC-10

UL-027 – Rechnung

Unveränderlicher Beleg über eine bereits autorisierte Bestellung und ihre eingefrorenen Werte.

• Perspektive: Finance
• Zugelassene Synonyme: Invoice
• Nicht verwenden: Zahlungsanforderung
• Status: accepted
• Use Cases: UC-06

UL-028 – Rechnungsnummer

Eindeutige, fachlich nachvollziehbare Identität einer Rechnung.

• Perspektive: Finance
• Zugelassene Synonyme: Invoice Number
• Nicht verwenden: Datenbankschlüssel
• Status: accepted
• Use Cases: UC-06

UL-029 – Rechnungssnapshot

Gesamtheit der bei Rechnungserstellung übernommenen Bestell-, Preis- und Adresswerte.

• Perspektive: Finance
• Zugelassene Synonyme: Belegsnapshot
• Nicht verwenden: Live-Produktdaten
• Status: accepted
• Use Cases: UC-06

UL-030 – Versandvorbereitung

Fachlicher Vorgang, der eine autorisierte und abrechenbare Bestellung für die operative Übergabe vorbereitet.

• Perspektive: Fulfillment
• Zugelassene Synonyme: Prepare Shipment
• Nicht verwenden: Versand
• Status: accepted
• Use Cases: UC-07

UL-031 – Versandauftrag

Verbindlicher Auftrag an die operative Auslieferung mit stabiler Identität und Bestellbezug.

• Perspektive: Fulfillment
• Zugelassene Synonyme: Shipment Order
• Nicht verwenden: Bestellung
• Status: accepted
• Use Cases: UC-07

UL-032 – Sendungsverfolgungsnummer

Kennung, mit der eine vorbereitete oder übergebene Sendung verfolgt wird.

• Perspektive: Fulfillment
• Zugelassene Synonyme: Tracking Number
• Nicht verwenden: Versand-ID
• Status: accepted
• Use Cases: UC-07

UL-033 – versandbereit

Zustand, in dem alle fachlichen Voraussetzungen für die operative Übergabe erfüllt sind.

• Perspektive: Fulfillment
• Zugelassene Synonyme: ready for shipment
• Nicht verwenden: versandt
• Status: accepted
• Use Cases: UC-07

UL-034 – Auslieferung

Operativer Vorgang nach Versandvorbereitung; der Begriff darf nicht für bloße Vorbereitung verwendet werden.

• Perspektive: Fulfillment
• Zugelassene Synonyme: Shipment
• Nicht verwenden: Versandvorbereitung
• Status: local
• Use Cases: UC-07

UL-035 – Benachrichtigung

Adressatengerechte Mitteilung über ein bereits entschiedenes fachliches Ergebnis.

• Perspektive: Kommunikation
• Zugelassene Synonyme: Notification
• Nicht verwenden: fachliche Entscheidung
• Status: accepted
• Use Cases: UC-08

UL-036 – Benachrichtigungsauftrag

Expliziter Auftrag, eine bestimmte Information über einen bestimmten Kanal an einen Empfänger zu senden.

• Perspektive: Kommunikation
• Zugelassene Synonyme: Notification Command
• Nicht verwenden: Domain Event
• Status: accepted
• Use Cases: UC-08

UL-037 – Audit-Nachweis

Unveränderlicher Nachweis, wer wann welche fachliche Entscheidung oder technische Übergabe ausgelöst hat.

• Perspektive: Audit
• Zugelassene Synonyme: Audit Entry
• Nicht verwenden: Logzeile
• Status: accepted
• Use Cases: UC-01, UC-02, UC-03, UC-04, UC-05, UC-06, UC-07, UC-08, UC-09, UC-10

UL-038 – Stornierung

Fachliche Entscheidung, eine Bestellung nicht weiter zu erfüllen; sie löst abhängige Rücknahmen aus, ersetzt sie aber nicht.

• Perspektive: Bestellung
• Zugelassene Synonyme: Cancel Order
• Nicht verwenden: Löschen
• Status: accepted
• Use Cases: UC-09

UL-039 – Kompensationsauftrag

Expliziter Auftrag, eine bereits erfolgte Zusage oder technische Wirkung fachlich auszugleichen.

• Perspektive: Prozess
• Zugelassene Synonyme: Compensation
• Nicht verwenden: Rollback
• Status: accepted
• Use Cases: UC-09, UC-10

UL-040 – manuelle Klärung

Bewusst sichtbarer Prozesszustand, wenn automatische Entscheidungen keine belastbare Fortsetzung erlauben.

• Perspektive: Prozess
• Zugelassene Synonyme: Manual Review
• Nicht verwenden: Fehler
• Status: accepted
• Use Cases: UC-10

UL-041 – Fachfehler

Erwartbares negatives Geschäftsergebnis mit stabiler Bedeutung, etwa unzureichender Bestand oder Zahlungsablehnung.

• Perspektive: Querschnitt
• Zugelassene Synonyme: Business Error
• Nicht verwenden: Exception
• Status: accepted
• Use Cases: UC-01, UC-02, UC-03, UC-04, UC-05, UC-09, UC-10

UL-042 – technische Störung

Nichtfachliche Unterbrechung, bei der das Geschäftsergebnis unbekannt oder nicht erreicht ist.

• Perspektive: Querschnitt
• Zugelassene Synonyme: Technical Failure
• Nicht verwenden: fachliche Ablehnung
• Status: accepted
• Use Cases: UC-05, UC-08, UC-10

UL-043 – Geschäftsregel

Explizite fachliche Bedingung, die eine Entscheidung begründet und durch Szenarien nachweisbar ist.

• Perspektive: Querschnitt
• Zugelassene Synonyme: Business Rule
• Nicht verwenden: Validierung
• Status: accepted
• Use Cases: UC-01, UC-02, UC-03, UC-04, UC-05, UC-06, UC-07, UC-08, UC-09, UC-10

UL-044 – Domänenereignis

Vergangenheitsform einer bereits innerhalb einer fachlichen Grenze getroffenen Entscheidung.

• Perspektive: Querschnitt
• Zugelassene Synonyme: Domain Event
• Nicht verwenden: Kafka-Nachricht
• Status: local
• Use Cases: UC-01, UC-02, UC-03, UC-04, UC-05, UC-06, UC-07

UL-045 – Integrationsereignis

Stabiler, versionierter Vertrag zur Mitteilung eines fachlichen Ergebnisses über eine Grenze hinweg.

• Perspektive: Integration
• Zugelassene Synonyme: Integration Event
• Nicht verwenden: internes Objekt
• Status: local
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07, UC-08

UL-046 – Prozesszustand

Explizite Aussage darüber, welche fachliche Zusage erreicht wurde und welche Entscheidung als Nächstes zulässig ist.

• Perspektive: Prozess
• Zugelassene Synonyme: Status
• Nicht verwenden: technisches Flag
• Status: accepted
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07, UC-09, UC-10

UL-047 – gleiche Absicht

Wiederholung mit identischem Idempotenzschlüssel und fachlich identischem Inhalt.

• Perspektive: Querschnitt
• Zugelassene Synonyme: same intent
• Nicht verwenden: gleiche URL
• Status: accepted
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07

UL-048 – Idempotenzkonflikt

Wiederholung eines Idempotenzschlüssels mit abweichendem fachlichem Inhalt.

• Perspektive: Querschnitt
• Zugelassene Synonyme: Idempotency Conflict
• Nicht verwenden: Duplikat
• Status: accepted
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07

UL-049 – Verkaufsfähigkeit

Entscheidung, ob ein Produkt grundsätzlich neu angeboten werden darf; sie sagt nichts über aktuelle Bestandsverfügbarkeit aus.

• Perspektive: Angebot
• Zugelassene Synonyme: Sellability
• Nicht verwenden: Verfügbarkeit
• Status: accepted
• Use Cases: UC-02, UC-03

UL-050 – Erfüllungszusage

Gesamte fachliche Zusage, dass Bestellung, Bestand, Zahlung und Versandvoraussetzungen in einem nachvollziehbaren Prozess fortgeführt werden.

• Perspektive: Prozess
• Zugelassene Synonyme: Fulfillment Promise
• Nicht verwenden: Bestellzusage
• Status: proposed
• Use Cases: UC-03, UC-04, UC-05, UC-06, UC-07

Semantische Konflikte

14 besonders riskante Mehrdeutigkeiten wurden explizit aufgelöst.

SK-01 – Bestellung

• Risiko: „Bestellung“ wird für Warenkorb, Entwurf und zugesagten Auftrag verwendet.
• Verbindliche Auflösung: Immer Bestellentwurf oder zugesagte Bestellung sagen.

SK-02 – verfügbar

• Risiko: „Verfügbar“ kann verkaufsfähig oder physisch reservierbar bedeuten.
• Verbindliche Auflösung: Verkaufsfähigkeit und verfügbarer Bestand getrennt benennen.

SK-03 – bezahlt

• Risiko: Autorisierung wird fälschlich als endgültige Zahlung bezeichnet.
• Verbindliche Auflösung: Zahlungsautorisierung verwenden; „bezahlt“ ist in diesem Projekt unzulässig.

SK-04 – reserviert

• Risiko: Bestand und Geld können beide reserviert sein.
• Verbindliche Auflösung: Bestandsreservierung oder Zahlungsautorisierung sagen.

SK-05 – Versand

• Risiko: Vorbereitung, Übergabe und Auslieferung werden vermischt.
• Verbindliche Auflösung: Versandvorbereitung, Versandauftrag und Auslieferung trennen.

SK-06 – Stornierung

• Risiko: Ein Begriff soll Bestellung, Bestand und Zahlung gleichzeitig rückgängig machen.
• Verbindliche Auflösung: Bestellstornierung löst Reservierungsfreigabe und gegebenenfalls Kompensationsaufträge aus.

SK-07 – Fehler

• Risiko: Fachliche Ablehnung und technische Störung werden gleich behandelt.
• Verbindliche Auflösung: Fachfehler und technische Störung unterscheiden.

SK-08 – Retry

• Risiko: Ein neuer Geschäftsauftrag wird als technische Wiederholung bezeichnet.
• Verbindliche Auflösung: Wiederholungsversuch nur bei gleicher Absicht und stabiler Identität.

SK-09 – Status

• Risiko: Ein globales Feld soll alle Prozessbedeutungen tragen.
• Verbindliche Auflösung: Immer Bestellstatus, Zahlungsstatus oder Versandzustand nennen.

SK-10 – Event

• Risiko: Interne Entscheidung und externer Vertrag werden gleichgesetzt.
• Verbindliche Auflösung: Domänenereignis und Integrationsereignis unterscheiden.

SK-11 – Produkt

• Risiko: Live-Katalogdaten werden nachträglich als Bestellinhalt gelesen.
• Verbindliche Auflösung: Produkt und Produkt-/Preis-Snapshot trennen.

SK-12 – Rechnung erstellt

• Risiko: Beleganlage wird mit Versand oder Zahlung verwechselt.
• Verbindliche Auflösung: Rechnungserstellung belegt autorisierte Bestellung; sie versendet und belastet nicht.

SK-13 – Kunde

• Risiko: Login-Konto und zulässige Geschäftsbeziehung werden gleichgesetzt.
• Verbindliche Auflösung: Kunde und aktive Kundenbeziehung explizit benennen.

SK-14 – Duplikat

• Risiko: Jede Wiederholung wird pauschal verworfen.
• Verbindliche Auflösung: Gleiche Absicht liefert dasselbe Ergebnis; abweichender Inhalt ist Idempotenzkonflikt.

Sprachregeln

SR-01 – Zustand im Begriff nennen

Mehrdeutige Hauptwörter erhalten einen Zustand: Bestellentwurf, zugesagte Bestellung, versandbereit.

SR-02 – Anfrage, Entscheidung und Ergebnis trennen

Reservierungsanfrage, Reservierungsentscheidung und Bestandsreservierung sind nicht dasselbe.

SR-03 – Keine Autorisierung als Zahlung bezeichnen

In diesem Projekt bedeutet Zahlungsautorisierung nur die positive Reservierungsentscheidung des Providers.

SR-04 – Snapshots ausdrücklich benennen

Historische Bestell- und Rechnungswerte dürfen nie als aktuelle Produktdaten beschrieben werden.

SR-05 – Fachfehler und Störung trennen

Fachfehler sind belastbare Ergebnisse; technische Störungen lassen das Ergebnis gegebenenfalls offen.

SR-06 – Ereignisse in Vergangenheitsform

Ein Ereignis heißt Bestellung zugesagt oder Bestand reserviert, nicht Bestellung zusagen.

SR-07 – Idempotenz ist fachlich

Gleicher Schlüssel reicht nicht: Auch die fachliche Absicht muss identisch sein.

SR-08 – Kein globaler Status

Jeder Zustand gehört zu einem klar benannten fachlichen Gegenstand.

SR-09 – Lokale Bedeutung sichtbar machen

Ein lokal verwendeter Begriff trägt Perspektive und Definition; er wird nicht stillschweigend globalisiert.

SR-10 – Technik nicht als Fachsprache tarnen

HTTP, Kafka, Tabelle, Entity oder Queue dürfen keine fachliche Entscheidung erklären.

SR-11 – Synonyme kontrollieren

Zugelassene Synonyme sind dokumentiert; verbotene Alternativen werden in Reviews korrigiert.

SR-12 – Neue Begriffe brauchen Nachweis

Ein Begriff wird erst akzeptiert, wenn Definition, Beispiel, Gegenbeispiel und Use-Case-Bezug vorhanden sind.

Gesprächsszenarien

Die Szenarien zeigen die Fachsprache in realistischen Abstimmungen. Sie sind keine technischen Sequenzdiagramme.

Bestellung zusagen

• Kundenservice Der aktive Kunde möchte zwei Produkte verbindlich bestellen.
• Bestellung Ich prüfe Verkaufsfähigkeit, positive Mengen und friere Namen sowie Preise ein.
• Bestellung Die Bestellung ist zugesagt. Das ist noch keine Bestands- oder Zahlungszusage.
• Audit Ich verknüpfe die Bestellzusage mit Korrelations- und Idempotenzkennung.

Bestand reservieren

• Bestellung Für die zugesagte Bestellung liegt eine Reservierungsanfrage vor.
• Bestand Ich prüfe alle Positionen atomar gegen den verfügbaren Bestand.
• Bestand Alle Positionen sind reserviert. Es gibt keine stille Teilreservierung.
• Prozess Die Erfüllung darf mit der Zahlungsentscheidung fortfahren.

Zahlung technisch unklar

• Finance Der Zahlungsversuch wurde gesendet, aber das technische Ergebnis ist nicht belastbar.
• Finance Der Zustand heißt Zahlungsunsicherheit, nicht Zahlungsablehnung.
• Prozess Ein Wiederholungsversuch verwendet dieselbe fachliche Zahlungsidentität.
• Audit Jeder Versuch bleibt nachvollziehbar; eine Doppelbelastung ist unzulässig.

Rechnung und Versand vorbereiten

• Finance Die Zahlungsautorisierung liegt vor. Ich erzeuge eine Rechnung aus unveränderlichen Snapshots.
• Fulfillment Die Bestellung wird versandbereit und erhält einen Versandauftrag.
• Fulfillment Versandvorbereitung bedeutet noch nicht Auslieferung.
• Kommunikation Ich benachrichtige den Kunden über bereits entschiedene Ergebnisse.

Bestellung stornieren

• Bestellung Die Bestellstornierung beendet die weitere Erfüllung.
• Bestand Ich führe eine Reservierungsfreigabe aus; die Menge wird wieder verfügbar.
• Finance Falls eine externe Wirkung entstanden ist, erhalte ich einen klaren Kompensationsauftrag.
• Prozess Nicht automatisch lösbare Fälle wechseln in manuelle Klärung.

Sprachpflege und Governance

Lebenszyklus

• vorgeschlagen: fachlich plausibel, aber noch nicht ausreichend belegt
• akzeptiert: Definition, Beispiel, Gegenbeispiel und Use-Case-Bezug sind vorhanden
• lokal: Bedeutung ist nur innerhalb einer klar benannten fachlichen Perspektive gültig
• veraltet: Begriff bleibt aus historischen Gründen sichtbar, darf aber nicht mehr neu verwendet werden

Änderungsprozess

1. Sprachproblem anhand eines konkreten Gesprächs, Szenarios oder Fehlers beschreiben.
2. Betroffene Perspektiven und Use Cases benennen.
3. Definition, zulässige Synonyme und unzulässige Alternativen formulieren.
4. Konflikt mit bestehenden Begriffen prüfen.
5. Entscheidung im fortlaufenden Entscheidungsdokument ergänzen.
6. Katalog, Beispiele, Schnittstellen und Tests gemeinsam aktualisieren.

Qualitätsfragen

• Kann ein Fachvertreter den Begriff ohne technische Erklärung verwenden?
• Ist klar, ob Anfrage, Entscheidung, Zustand oder Ergebnis gemeint ist?
• Ist die Bedeutung zeitlich stabil oder ein Snapshot notwendig?
• Gibt es eine lokale Bedeutung, die nicht globalisiert werden darf?
• Ist ein Gegenbeispiel dokumentiert?

Sprachliche Rückverfolgbarkeit

Jeder gemeinsame Use Case ist mit den für seine fachliche Aussage notwendigen Begriffen verbunden.

UC-01

• UL-001 Kunde
• UL-002 Kundenkennung
• UL-003 aktive Kundenbeziehung
• UL-037 Audit-Nachweis
• UL-041 Fachfehler
• UL-043 Geschäftsregel
• UL-044 Domänenereignis

UC-02

• UL-004 Produkt
• UL-005 Artikelnummer
• UL-006 verkaufsfähig
• UL-007 Verkaufspreis
• UL-037 Audit-Nachweis
• UL-041 Fachfehler
• UL-043 Geschäftsregel
• UL-044 Domänenereignis
• UL-049 Verkaufsfähigkeit

UC-03

• UL-001 Kunde
• UL-002 Kundenkennung
• UL-003 aktive Kundenbeziehung
• UL-004 Produkt
• UL-005 Artikelnummer
• UL-006 verkaufsfähig
• UL-007 Verkaufspreis
• UL-008 Preis-Snapshot
• UL-009 Bestellentwurf
• UL-010 Bestellung
• UL-011 Bestellposition
• UL-012 Bestellzusage
• UL-013 Idempotenzschlüssel
• UL-014 Korrelationskennung
• UL-037 Audit-Nachweis
• UL-041 Fachfehler
• UL-043 Geschäftsregel
• UL-044 Domänenereignis
• UL-045 Integrationsereignis
• UL-046 Prozesszustand
• UL-047 gleiche Absicht
• UL-048 Idempotenzkonflikt
• UL-049 Verkaufsfähigkeit
• UL-050 Erfüllungszusage

UC-04

• UL-013 Idempotenzschlüssel
• UL-014 Korrelationskennung
• UL-015 Bestandsposition
• UL-016 verfügbarer Bestand
• UL-017 Reservierungsanfrage
• UL-018 Bestandsreservierung
• UL-020 vollständige Reservierung
• UL-037 Audit-Nachweis
• UL-041 Fachfehler
• UL-043 Geschäftsregel
• UL-044 Domänenereignis
• UL-045 Integrationsereignis
• UL-046 Prozesszustand
• UL-047 gleiche Absicht
• UL-048 Idempotenzkonflikt
• UL-050 Erfüllungszusage

UC-05

• UL-013 Idempotenzschlüssel
• UL-014 Korrelationskennung
• UL-021 Zahlungsversuch
• UL-022 Zahlungsautorisierung
• UL-023 Zahlungsablehnung
• UL-024 Zahlungsunsicherheit
• UL-025 Zahlungsreferenz
• UL-026 Wiederholungsversuch
• UL-037 Audit-Nachweis
• UL-041 Fachfehler
• UL-042 technische Störung
• UL-043 Geschäftsregel
• UL-044 Domänenereignis
• UL-045 Integrationsereignis
• UL-046 Prozesszustand
• UL-047 gleiche Absicht
• UL-048 Idempotenzkonflikt
• UL-050 Erfüllungszusage

UC-06

• UL-008 Preis-Snapshot
• UL-011 Bestellposition
• UL-013 Idempotenzschlüssel
• UL-014 Korrelationskennung
• UL-022 Zahlungsautorisierung
• UL-027 Rechnung
• UL-028 Rechnungsnummer
• UL-029 Rechnungssnapshot
• UL-037 Audit-Nachweis
• UL-043 Geschäftsregel
• UL-044 Domänenereignis
• UL-045 Integrationsereignis
• UL-046 Prozesszustand
• UL-047 gleiche Absicht
• UL-048 Idempotenzkonflikt
• UL-050 Erfüllungszusage

UC-07

• UL-013 Idempotenzschlüssel
• UL-014 Korrelationskennung
• UL-030 Versandvorbereitung
• UL-031 Versandauftrag
• UL-032 Sendungsverfolgungsnummer
• UL-033 versandbereit
• UL-034 Auslieferung
• UL-037 Audit-Nachweis
• UL-043 Geschäftsregel
• UL-044 Domänenereignis
• UL-045 Integrationsereignis
• UL-046 Prozesszustand
• UL-047 gleiche Absicht
• UL-048 Idempotenzkonflikt
• UL-050 Erfüllungszusage

UC-08

• UL-014 Korrelationskennung
• UL-035 Benachrichtigung
• UL-036 Benachrichtigungsauftrag
• UL-037 Audit-Nachweis
• UL-042 technische Störung
• UL-043 Geschäftsregel
• UL-045 Integrationsereignis

UC-09

• UL-010 Bestellung
• UL-018 Bestandsreservierung
• UL-019 Reservierungsfreigabe
• UL-037 Audit-Nachweis
• UL-038 Stornierung
• UL-039 Kompensationsauftrag
• UL-041 Fachfehler
• UL-043 Geschäftsregel
• UL-046 Prozesszustand

UC-10

• UL-023 Zahlungsablehnung
• UL-024 Zahlungsunsicherheit
• UL-026 Wiederholungsversuch
• UL-037 Audit-Nachweis
• UL-039 Kompensationsauftrag
• UL-040 manuelle Klärung
• UL-041 Fachfehler
• UL-042 technische Störung
• UL-043 Geschäftsregel
• UL-046 Prozesszustand

Subdomain-Klassifikation

Zweck

Die fachlichen Fähigkeiten aus der Discovery und die präzisierte Fachsprache werden strategisch eingeordnet. Die Klassifikation beantwortet, wo differenzierendes Wissen liegt und wie stark investiert werden soll.

Core Domain

• Order Promise Bestellzusage, Preis-Snapshot, Bestellzustand und Stornierbarkeit.
• Availability Commitment atomare Bestandszusage, Ablehnung und Freigabe.
• Exception Recovery Retry, Unsicherheit, Kompensation und manuelle Klärung.

Supporting Subdomains

Customer Relationship, Sellable Catalog, Payment Authorization Policy, Billing Evidence und Fulfillment Preparation sind für den Gesamtprozess erforderlich, bilden aber nicht allein die strategische Differenzierung.

Generic Subdomains

Notification Delivery sowie Audit & Operational Reporting werden möglichst standardisiert, eingekauft oder als Plattformfähigkeit genutzt.

Wichtige Grenze

Subdomain ist keine technische Modulbezeichnung und kein Bounded Context. Mehrere Subdomains können später in einem Kontext zusammenarbeiten; eine Subdomain kann bei hoher Komplexität auch mehrere Kontextgrenzen erfordern.

Core-Domain-Strategie

Strategisches Ziel

Die Core Domain konzentriert sich auf die Qualität und Belastbarkeit von Zusagen. Entscheidend ist nicht die reine Erfassung einer Bestellung, sondern ob das System eine nachvollziehbare, erfüllbare und bei Störungen kontrolliert korrigierbare Zusage gibt.

Order Promise

Diese Subdomain entscheidet, ob aus einem Bestellentwurf eine Bestellzusage wird. Sie besitzt die Regeln für aktive Kundenbeziehung, Verkaufsfähigkeit, Preis-Snapshot, Bestellpositionen und Stornierbarkeit.

Availability Commitment

Diese Subdomain schützt die atomare Bestandszusage. Eine Teilreservierung darf nicht als erfolgreiche Erfüllungszusage erscheinen.

Exception Recovery

Diese Subdomain behandelt fachliche Fehlschläge und technische Unsicherheit explizit. Sie verhindert, dass Retry, Kompensation und manuelle Klärung in technischen Adaptern verschwinden.

Investitionsprinzipien

• beste Domänenexpertise auf Core-Domain-Fragen konzentrieren
• Fachregeln durch ausführbare Beispiele sichern
• Standardsoftware nur hinter klaren fachlichen Grenzen integrieren
• Core-Domain-Modell nicht nach Anbieterobjekten oder Datenbankschemata formen

Investitionsentscheidungen

Build Deep

Order Promise, Availability Commitment und Exception Recovery werden selbst entwickelt und fachlich vertieft. Hier entstehen differenzierende Regeln und Lernwert.

Build Lean

Customer Relationship, Sellable Catalog und Billing Evidence werden selbst, aber bewusst schlank modelliert. Fulfillment Preparation bleibt eine interne Vorbereitung; physische Logistik wird über Partner angebunden.

Build Policy, Partner Rail

Bei Payment Authorization Policy bleibt die fachliche Retry-, Ablehnungs- und Unsicherheitslogik intern. Der eigentliche Zahlungsrail wird über einen austauschbaren Provider integriert.

Buy oder Managed Service

Notification Delivery sowie Audit & Operational Reporting werden bevorzugt als Standard- oder Plattformfähigkeit behandelt. Eigene Entwicklung ist nur gerechtfertigt, wenn konkrete regulatorische oder differenzierende Anforderungen entstehen.

Architekturfolge

Die Investitionsentscheidung legt keine konkrete Technologie fest. Sie beeinflusst Tiefe, Testintensität, Teamzuordnung und Schutz der späteren Kontextgrenzen.

Subdomain-Rückverfolgbarkeit

Vollständigkeit

Alle zehn gemeinsamen Use Cases sind mindestens einer primären Subdomain zugeordnet. Cross-Cutting-Nachweise werden nicht als fachliche Eigentümer missverstanden.

Use-Case-Zuordnung

• UC-01: Customer Relationship
• UC-02: Sellable Catalog
• UC-03: Order Promise
• UC-04: Availability Commitment
• UC-05: Payment Authorization Policy
• UC-06: Billing Evidence
• UC-07: Fulfillment Preparation
• UC-08: Notification Delivery
• UC-09: Order Promise, Availability Commitment und Exception Recovery
• UC-10: Payment Authorization Policy und Exception Recovery

Folge für die nächste Umsetzung

Die Subdomain-Karte liefert Kandidaten, aber noch keine Bounded Contexts. prüft Sprachgrenzen, Datenhoheit, Teamautonomie, Konsistenz und Integrationsdruck separat.

Bounded Contexts

Zweck

Ein Bounded Context schützt die lokale Bedeutung eines Modells. Innerhalb der Grenze gelten eine gemeinsame Fachsprache, klare Entscheidungshoheit und eindeutige Datenverantwortung.

Abgeleitete Kontexte

• Customer Context
• Catalog Context
• Ordering Context
• Inventory Context
• Payment Context
• Billing Context
• Fulfillment Context
• Recovery Context
• Communication Context
• Operations Insight Context

Keine technische Kurzschlussentscheidung

Die Kontextnamen sind keine vorweggenommenen Microservices, Datenbanken oder Maven-Module. Eine spätere Deployment-Struktur kann mehrere Kontexte gemeinsam ausliefern, solange Modell- und Eigentumsgrenzen erhalten bleiben.

Strategische Zuordnung

Ordering, Inventory und Recovery schützen die drei Core Domains. Customer, Catalog, Payment, Billing und Fulfillment bilden Supporting Contexts. Communication und Operations Insight kapseln Generic Capabilities.

Kontextgrenzen

Ableitungskriterien

Eine Grenze wird nur akzeptiert, wenn sie durch mehrere Signale getragen wird

1. eigene Fachsprache
2. eigene Entscheidungshoheit
3. eindeutige Datenhoheit
4. lokale Konsistenzregeln
5. unabhängiger Veränderungsrhythmus
6. verantwortliches Team
7. Übersetzungsbedarf an der Grenze

Kritische Trennungen

Catalog und Ordering

Catalog besitzt den aktuellen Angebotspreis. Ordering besitzt den unveränderlichen Preis-Snapshot einer zugesagten Bestellung. Eine spätere Preisänderung darf bestehende Bestellungen nicht verändern.

Ordering und Inventory

Ordering entscheidet über die Bestellzusage. Inventory entscheidet atomar über Verfügbarkeit und Reservierung. Keine Seite schreibt den Zustand der anderen direkt.

Payment und Recovery

Payment deutet einzelne Autorisierungsversuche. Recovery entscheidet über den übergreifenden Umgang mit Unsicherheit, Retry und manueller Klärung.

Fulfillment und externer Logistikpartner

Fulfillment besitzt die interne Vorbereitung und Partnerübergabe. Physische Lager- und Transportausführung bleibt außerhalb des Modells.

Operations Insight und operative Kontexte

Operations Insight projiziert veröffentlichte Aussagen, darf aber keine operativen Fachzustände zurückschreiben.

Daten- und Entscheidungshoheit

Eigentumsregel

Ein fachliches Datum besitzt genau einen schreibenden Eigentümerkontext. Gemeinsame Tabellen, direkte Fremdschlüsseländerungen und kontextübergreifende Repository-Nutzung sind nicht zulässig.

Beispiele

• Customer Context besitzt den Kundenbeziehungsstatus.
• Catalog Context besitzt aktuellen Verkaufsstatus und Listenpreis.
• Ordering Context besitzt Bestellstatus und Bestell-Snapshot.
• Inventory Context besitzt verfügbare und reservierte Menge.
• Payment Context besitzt Autorisierungsstatus und Versuchshistorie.
• Billing Context besitzt Rechnungsnummer und Rechnungsnachweis.
• Recovery Context besitzt Recovery-Fall und Retry-Entscheidung.
• Operations Insight besitzt ausschließlich Projektionen und Auditnachweise.

Lesemodelle

Andere Kontexte dürfen benötigte Informationen über synchrone Abfragen, veröffentlichte Ereignisse oder lokale Projektionen beziehen. Die technische Wahl wird später pro Beziehung begründet.

Konsistenzregel

Unmittelbare Konsistenz endet grundsätzlich an der Kontextgrenze. Kontextübergreifende Abläufe werden als verteilte fachliche Prozesse mit expliziten Zwischenzuständen behandelt.

Kontext-Rückverfolgbarkeit

Subdomain-Zuordnung

Jede der zehn Subdomains besitzt einen primären Kontextkandidaten. Diese Eins-zu-eins-Zuordnung ist ein Ergebnis des aktuellen Lernumfangs, keine allgemeine DDD-Regel.

Use-Case-Abdeckung

Alle zehn gemeinsamen Use Cases sind mindestens einem entscheidenden Kontext zugeordnet. UC-09 und UC-10 schneiden bewusst mehrere Kontexte und werden später über Beziehungsmuster und Prozesskoordination präzisiert.

Boundary-Evaluation

Alle Kontextkandidaten wurden gegen sieben Kriterien geprüft: Sprache, Entscheidungshoheit, Datenhoheit, Konsistenz, Veränderungsrhythmus, Teamautonomie und Übersetzungsbedarf.

Folge für die nächste Umsetzung

klassifiziert die Beziehungen zwischen den Kontexten. Erst dort werden Customer/Supplier, Published Language, Anti-Corruption Layer, Open Host Service oder Separate Ways entschieden.

Context Map

Zweck

Die Context Map macht sichtbar, wie die zehn Bounded Contexts zusammenarbeiten, wer einen Vertrag besitzt, wer Einfluss auf dessen Entwicklung hat und wo Übersetzung notwendig ist.

Kernbeziehungen

• Ordering und Inventory arbeiten als Partnership an der Bestellzusage.
• Ordering und Recovery arbeiten als Partnership an Fehler- und Kompensationsabläufen.
• Customer, Catalog, Payment, Billing und Fulfillment verwenden klar gerichtete Customer/Supplier-Beziehungen.
• Externe Zahlungs- und Logistiksysteme werden durch Anti-Corruption Layer abgeschirmt.
• Communication stellt einen Open Host Service mit Published Language bereit.
• Operations Insight akzeptiert veröffentlichte Ereignisse als read-only Conformist.
• Unnötige oder gefährliche Rückkopplungen werden als Separate Ways dokumentiert.

Keine technische Gleichsetzung

Die Context Map ist eine fachliche Beziehungslandkarte. Sie entscheidet noch nicht über Maven-Module, Prozesse, Container, Datenbanken oder Netzwerkgrenzen.

Beziehungsmuster

Partnership

Zwischen Ordering und Inventory sowie zwischen Ordering und Recovery müssen beide Seiten Verträge gemeinsam entwickeln und koordinieren. Keine Seite kann die Beziehung einseitig optimieren.

Customer/Supplier

Der Downstream-Kunde beeinflusst den Vertrag des Upstream-Suppliers. Dieses Muster wird für Kundenberechtigung, Angebot, Zahlungsresultat, Abrechnung und Versandfreigabe verwendet.

Anti-Corruption Layer

Payment, Fulfillment und Recovery übersetzen fremde Status- und Fehlermodelle in ihre eigene Fachsprache. Provider-, Partner- oder Nachbarkontextdetails gelangen nicht in den Fachkern.

Open Host Service und Published Language

Wiederverwendbare Integrationspunkte besitzen einen stabilen Dienst oder Nachrichtenvertrag. Versionierung, Idempotenz und additive Weiterentwicklung sind Teil des Vertrags.

Conformist

Nur Operations Insight akzeptiert veröffentlichte Ereignisse ohne Einfluss auf die Produzenten. Das ist vertretbar, weil die Projektion read-only und nicht geschäftsentscheidend ist.

Separate Ways

Kein Rückschreiben von Operations Insight nach Ordering und keine direkte Kopplung zwischen Customer und Catalog. Nicht jede mögliche Verbindung ist fachlich sinnvoll.

Integrationsverträge

Vertragsprinzipien

Jede aktive Beziehung verweist auf einen expliziten Vertrag mit Eigentümer, Konsumenten, Stil, Version, Nutzdaten, Kompatibilitätsregel und Idempotenzschlüssel.

Synchrone Abfragen

Customer Eligibility, Current Offer und Order Billing Snapshot sind read-only Abfragen. Sie übertragen nur die für den Downstream erforderlichen Fakten.

Asynchrone Verträge

Inventory Commitment, Payment Outcomes, Invoice Issued, Recovery Coordination und Notification Request sind versionierte Nachrichtenverträge. Mehrfachzustellung und verzögerte Verarbeitung werden ausdrücklich berücksichtigt.

Externe Adapter

Payment Provider und Logistics Partner werden nicht als fachliche Modelle übernommen. Adapter übersetzen technische Antworten in lokale Fachbegriffe.

Betriebsprojektionen

Der Business Event Envelope ist eine Published Language für read-only Audit- und Betriebsmodelle. Operative Kontexte werden dadurch nicht steuerbar.

Context-Map-Rückverfolgbarkeit

Abdeckung

Alle zehn internen Bounded Contexts sind in mindestens einer aktiven Beziehung beteiligt. Externe Provider und die Integrationsplattform sind als eigene Knoten sichtbar.

Musterabdeckung

Die Context Map verwendet Partnership, Customer/Supplier, Anti-Corruption Layer, Open Host Service, Published Language, Conformist und Separate Ways. Shared Kernel, globales kanonisches Modell und direkte Datenbankintegration wurden begründet abgelehnt.

Vertragsabdeckung

Jede aktive Beziehung besitzt einen Vertrag. Separate-Ways-Beziehungen besitzen bewusst keinen Integrationsvertrag.

Übersetzungsabdeckung

Jede Anti-Corruption-Layer-Beziehung benennt einen lokalen Übersetzungseigentümer. Die Übersetzungsmatrix dokumentiert konkrete Quell- und Zielbegriffe.

Folge für die nächste Umsetzung

Value Objects werden erst jetzt aus der stabilisierten Fachsprache und den Kontextgrenzen abgeleitet. Ein gleichnamiger Wert kann je Kontext unterschiedliche Regeln besitzen.

Value Objects

Definition

Ein Value Object wird vollständig durch seine Werte beschrieben. Es besitzt keine fachliche Identität, ist unveränderlich und ist bereits bei erfolgreicher Konstruktion gültig.

Implementierte Typen

Customer besitzt CustomerId, EmailAddress und PostalAddress. Catalog besitzt ProductId und Money. Ordering besitzt eigene Referenztypen, Preis-Snapshots, Quantity und ShippingAddress. Inventory besitzt eigene Bestandswerte. Payment besitzt PaymentReference und einen strikt positiven Geldbetrag.

Invarianten an der Grenze

Ungültige Werte werden nicht in das Modell aufgenommen. Normalisierung findet vor der Validierung und vor der record-basierten Gleichheit statt.

Immutability

Alle Typen sind Java Records. Rechenoperationen und Reservierungen erzeugen neue Instanzen; der Ausgangswert bleibt unverändert.

Kontextlokale Semantik

Kein globales Money

Catalog-Money erlaubt einen kostenlosen Listenpreis. Ordering-Money ist ein historischer Snapshot und unterstützt nur gleichwährungsfähige Berechnungen. Payment-Money muss strikt positiv sein.

Kein globales ProductId

Catalog besitzt die Angebotsidentität. Ordering speichert eine Referenz im Bestellkontext. Inventory verwendet denselben Vertragswert als Bestandsschlüssel. Die Syntax ist kompatibel, die Typen und Owner bleiben getrennt.

Kein globales Quantity

Eine Bestellmenge liegt zwischen 1 und 999. Ein Bestand darf null sein, besitzt eine andere Obergrenze und kennt die sichere Reservierung.

Adressen sind Snapshots mit unterschiedlichem Zweck

PostalAddress ist Kundenstammdatenwert. ShippingAddress ist ein unveränderlicher Liefer-Snapshot mit Empfänger. Beide dürfen unabhängig weiterentwickelt werden.

Validierung und Fehlerfälle

Fail fast

Jeder Konstruktor lehnt null, Leerwerte, fehlerhafte Formate und ungültige Wertebereiche sofort ab. Es existiert kein teilweise gültiger Zustand.

Normalisierung

Identifier werden getrimmt und großgeschrieben, E-Mail-Adressen kleingeschrieben, Länderkennungen normalisiert und Geldbeträge auf zwei Nachkommastellen gerundet.

Operationale Fehler

Ungültige Konstruktion führt zu IllegalArgumentException. Eine fachlich unmögliche Reservierung führt zu IllegalStateException, weil ein gültiger Bestand eine unzulässige Operation abweist.

Keine versteckte Währungsumrechnung

Ordering addiert nur gleiche Währungen. Währungsumrechnung wäre ein eigener fachlicher Prozess und gehört nicht in das Value Object.

Value-Object-Rückverfolgbarkeit

Quellen

Jeder Werttyp ist auf Ubiquitous Language, Bounded Context, Geschäftsregel und Integrationsvertrag zurückgeführt. Dadurch ist er keine technische Convenience-Klasse, sondern ein fachlich begründetes Modellteil.

Abdeckung

Fünfzehn Value Objects decken Identitäten, Referenzen, Geld, Mengen, Kontakt- und Adresswerte ab. Fünf semantische Namenskollisionen wurden explizit getrennt.

Qualitätsnachweise

Die Prüfung kontrolliert record-basierte Unveränderlichkeit, Konstruktorvalidierung, Normalisierung, Gleichheit, kontextlokale Klassen, Java-21-Kompilierung und einen ausführbaren Smoke-Test.

Folge für die nächste Umsetzung

Entities und Aggregate-Kandidaten werden auf diesen bereits gültigen Werten aufgebaut. Value Objects enthalten noch keine Entity-Identität oder Aggregate-Lebenszyklen.

Entities: Identität und Lebenszyklus

Entities werden nicht durch alle Attribute, sondern durch eine stabile fachliche Identität erkannt. Eine geänderte E-Mail-Adresse erzeugt deshalb keinen neuen Kunden; eine Preisänderung erzeugt kein neues Katalogprodukt.

Implementierte Referenz-Entities

• CustomerProfileaktive, gesperrte und geschlossene Kundenidentität
• CatalogProductEntwurf, aktives Angebot und ausgemustertes Produkt
• OrderLineCandidateinterne Entity innerhalb eines Bestellentwurfs
• PaymentAttemptCandidateidentischer Zahlungsversuch mit terminalem Ergebnis

Regeln

1. Gleichheit und Hashcode basieren ausschließlich auf der fachlichen Identität.
2. Zustandsänderungen erfolgen über benannte Fachmethoden, nicht über Setter.
3. Terminale Zustände blockieren unzulässige Folgemutationen.
4. Value Objects bleiben attributsbasiert; nur echte Lebenszyklen erhalten Identität.

Aggregate-Kandidaten

Aggregate werden aus Konsistenzregeln abgeleitet, nicht aus Tabellen, UI-Seiten oder Objektgraphen. bewertet zehn Kandidaten und implementiert nur repräsentative Modelle.

Zentrale Entscheidung

Der Order-Kandidat umfasst Order, OrderLine, Lieferadress- und Preissnapshots. Bestand, Zahlung, Rechnung und Versand bleiben außerhalb dieser Grenze. Der Order-Kandidat darf sie nur über Verträge und Ereignisse koordinieren.

Kandidatenstatus

• ausgewählt: CustomerProfile, CatalogProduct, StockItem
• für die nächste Umsetzung ausgewählt: Order
• für die nächste Umsetzung zurückgestellt: Reservation und Payment
• später: Invoice, Shipment, DeliveryAttempt und RecoveryCase

Konsistenzgrenzen

Innerhalb eines Aggregats gelten Invarianten sofort. Zwischen Bounded Contexts werden Zustände über versionierte Verträge, Ereignisse, Idempotenz und Wiederanlauf abgestimmt.

Beispiele

• Eine platzierte Bestellung ist unmittelbar gegen Positionsänderungen geschützt.
• Ein StockItem verhindert Bestandsunterlauf unmittelbar.
• Der Bestellstatus folgt einer Reservierungsentscheidung erst über den Integrationsvertrag.
• Eine Rechnung übernimmt einen unveränderlichen Bestellsnapshot und hält keine direkte Order-Referenz.

Eine gemeinsame Datenbanktransaktion über Ordering, Inventory, Payment und Billing wird ausdrücklich verworfen.

Aggregate-Smells und verworfene Modelle

Warnzeichen

• ein Aggregate enthält mehrere Bounded Contexts
• jede Datenbankbeziehung wird als Objektbeziehung modelliert
• öffentliche Setter umgehen Fachmethoden
• identische mutable Entities werden zwischen Kontexten geteilt
• ein UI-Bildschirm bestimmt die Konsistenzgrenze
• ein Aggregate lädt unbeschränkt wachsende Sammlungen

Leitregel

So klein wie möglich, so groß wie für eine unmittelbar durchzusetzende Invariante nötig. Referenzen zu anderen Aggregaten werden über Identitäten und lokale Snapshots geführt.

Ordering Aggregate

Der im entsprechenden Kapitel ausgewählte Kandidat ist nun als vollständiger Java-21-Aggregate-Root umgesetzt. Order kontrolliert ausschließlich den Bestellentwurf und seine OrderLineEntities. Bestand, Zahlungsautorisierung, Rechnung und Versand bleiben außerhalb dieser unmittelbaren Konsistenzgrenze.

Grenze

Innerhalb: OrderId, Customer-Referenz, Versand-Snapshot, Status, OrderLines, Preis- und Produkt-Snapshots sowie Pending Domain Events.

Außerhalb: Kundenlebenszyklus, Produktaktivierung, verfügbarer Bestand, Zahlungsstatus, Rechnung und Versandstatus.

Fachmethoden

• Bestellentwurf über die Factory erzeugen
• Position hinzufügen, Menge ändern oder Position entfernen
• Gesamtsumme aus unveränderlichen Snapshots berechnen
• nichtleeren Entwurf aufgeben
• Bestellung idempotent stornieren
• Domain Events einmalig an den späteren Application Layer übergeben

Ordering-Invarianten

Neun ausführbare Invarianten schützen die Aggregate-Grenze. Änderungen erfolgen ausschließlich über die Root; die Positionssammlung ist nach außen unveränderlich. Eine aufgegebene oder stornierte Bestellung kann nicht mehr strukturell verändert werden.

Die Geschäftsregeln zur Idempotency eines Use Cases sowie zur Prüfung aktiver Kunden und Produkte gehören bewusst nicht in die Root. Sie benötigen externe Verträge und werden im Application Layer von orchestriert.

Ordering Domain Events

Sechs interne Domain Events beschreiben bereits eingetretene fachliche Änderungen. Sie enthalten ausschließlich Ordering-Begriffe und sind noch keine externen Integrationsereignisse. Die Übersetzung in versionierte Published-Language-Verträge folgt an der Kontextgrenze.

Die Root sammelt Ereignisse in einer gekapselten Pending-Liste. pullDomainEvents liefert eine unveränderliche Kopie und leert die interne Liste, sodass ein Application Service sie genau einmal an Repository und Publisher übergeben kann.

Ordering Tests und Rückverfolgbarkeit

Zehn JUnit-Tests dokumentieren die Aggregate-Regeln. Ein zusätzlicher Java-21-Smoke-Test prüft Konstruktion, Zustände, Invarianten, Snapshots, Ereignisse, Versionierung, Idempotenz und Kapselung ohne Maven-Laufzeit.

BR-ORD-001 und BR-ORD-002 werden direkt durch die Root geschützt. BR-ORD-003 und BR-ORD-004 bleiben bewusst dem Application Layer vorbehalten, weil Idempotency sowie Kunden- und Produktberechtigung externe Informationen benötigen.

Inventory Aggregate

StockItem ist Aggregate Root für genau ein Produkt. Es schützt den verfügbaren Bestand und identitätsbehaftete Reservierungen atomar. Produktkatalog, Bestellung, Zahlung und Versand bleiben außerhalb der unmittelbaren Konsistenzgrenze.

Die Reservierung reduziert den verfügbaren Bestand nur nach vollständiger Vorprüfung. Gleiche Reservierungsidentität mit gleichem Inhalt ist idempotent; eine konfliktbehaftete Wiederverwendung wird abgelehnt. Freigaben erhöhen den Bestand höchstens einmal.

Inventory Invarianten und Domain Events

Zehn Invarianten schützen Menge, Identität, Reservierungslebenszyklus, Idempotenz und Kapselung. Vier interne Domain Events beschreiben Registrierung, Auffüllung, Reservierung und Freigabe.

Die Ereignisse sind noch keine externen Integrationsverträge. Ihre Übersetzung in Published-Language-Ereignisse erfolgt später am Context-Rand.

Payment Aggregate

Payment schützt einen unveränderlichen Zahlungsauftrag und bis zu drei sequenzielle Autorisierungsversuche. Jeder Versuch ist eine identitätsbehaftete Entity. Provider-Aufruf, Timer, Persistenz und Transport bleiben außerhalb der Domain.

Autorisierung, fachliche Ablehnung und endgültiger Fehlschlag sind terminal. Nur ein klassifizierter technischer Fehler öffnet den Weg für einen neuen Versuch.

Payment Retry und Idempotenz

Die Retry-Politik ist fachlich explizit: maximal drei Versuche, niemals zwei parallele Versuche und keine Wiederholung nach Autorisierung oder fachlicher Ablehnung. Eine bekannte AttemptId erzeugt keinen zweiten Versuch.

Ein technischer Fehler setzt den Zustand auf Retry Pending. Nach dem dritten technischen Fehler wird Payment endgültig als Failed abgeschlossen und publiziert ein eigenes Domain Event.

Inventory und Payment Tests und Rückverfolgbarkeit

Neun Inventory- und neun Payment-Tests dokumentieren die Aggregate-Regeln. Zwei eigenständige Java-21-Smoke-Tests prüfen Invarianten, Zustände, Idempotenz, Ereignisse, Retry-Grenze und Kapselung ohne Maven-Laufzeit.

Die Rückverfolgbarkeit verbindet gemeinsame Geschäftsregeln mit Aggregate-Invarianten, Produktionscode und konkreten Tests.

Application Layer

Verantwortung

Der Application Layer übersetzt eine konkrete Benutzer- oder Systemabsicht in einen kontrollierten Ablauf. Er öffnet die passende Transaktionsgrenze, lädt genau die benötigte Aggregate Root, delegiert alle fachlichen Entscheidungen an das Domain-Modell, speichert den neuen Zustand und übergibt die entstandenen Domain Events an einen transaktionalen Ausgangsport.

Er enthält keine Regeln darüber, ob eine leere Bestellung aufgegeben werden darf, ob Bestand ausreicht oder wie viele Zahlungsversuche zulässig sind. Diese Entscheidungen bleiben in Order, StockItem und Payment. Der Application Layer entscheidet dagegen, wann geladen, wann gespeichert, wann ein Provider aufgerufen und welche Projektion an einen Adapter zurückgegeben wird.

Modulgrenzen

Jeder Bounded Context erhält ein eigenes Application-Modul. Ordering, Inventory und Payment importieren einander nicht. Damit kann kein Handler versehentlich direkt auf Repositories oder Aggregate eines anderen Contexts zugreifen. Kontextübergreifende Abläufe werden erst über Integrationsverträge und Process Manager verbunden.

Ablauf eines Commands

1. Command validieren und Idempotenzidentität übernehmen.
2. Lokale Transaktion öffnen.
3. Aggregate Root über Repository Port laden oder erzeugen.
4. Fachliche Methode der Aggregate Root aufrufen.
5. Aggregate speichern.
6. Domain Events innerhalb derselben Transaktion an den Event-Publisher-Port übergeben.
7. Unveränderliche View zurückgeben.

Commands und Queries

Commands verändern Zustand und tragen eine stabile fachliche Identität. Queries verändern keinen Domainzustand und liefern ausschließlich Projektionen. Die Aggregate Roots selbst werden niemals an REST-, Messaging- oder Batch-Adapter zurückgegeben.

Domain Services

führt bewusst keinen künstlichen Domain Service ein. Alle aktuellen Regeln gehören eindeutig zu einer Aggregate Root. Ein Domain Service wäre erst gerechtfertigt, wenn eine rein fachliche Operation mehrere Domain-Objekte benötigt, keinem Objekt natürlich gehört, keine Infrastruktur orchestriert und dennoch eine eigene fachliche Sprache besitzt. Provider-Aufrufe, Transaktionen und Ereignispublikation sind keine Domain Services, sondern Application- und Adapterverantwortung.

Ordering Application

Use Cases

Das Ordering-Application-Modul unterstützt Bestellentwurf anlegen, Position hinzufügen, Bestellung aufgeben, Bestellung stornieren und Bestellung abfragen. Jede Absicht besitzt einen eigenen Command oder eine Query sowie einen klar benannten Handler.

Idempotenz

OrderId und OrderLineId werden vom aufrufenden Adapter geliefert. Eine wiederholte Anlage mit identischem Inhalt liefert dieselbe Projektion. Wird dieselbe Identität mit abweichenden Daten verwendet, entsteht ein Application-Konflikt. Dadurch wird Transportwiederholung nicht mit fachlicher Doppelwirkung verwechselt.

Transaktion und Events

Handler führen Laden, Zustandsänderung, Speichern und Outbox-Übergabe innerhalb einer Transaktionsgrenze aus. Der Event-Publisher-Port ist kein direkter Broker-Client. Sein späterer Adapter muss die Events transaktional persistieren. Erst ein separater Dispatcher überträgt sie an Messaging-Infrastruktur.

Projektionen

OrderView und OrderLineView enthalten nur unveränderliche Werte. Adapter können daraus HTTP-Antworten, Nachrichten oder Batch-Ausgaben erzeugen, ohne Methoden der Aggregate Root aufzurufen.

Muster

Command, Command Handler, Query, Query Handler, Repository Port, Clock Port, Transaction Boundary, Event Publisher Port, Query Projection und Application Service Facade sind im Code markiert.

Inventory Application

Use Cases

Das Inventory-Application-Modul registriert Bestand, verbucht Nachschub, reserviert Bestand, gibt Reservierungen frei und liefert Bestandsprojektionen.

Atomare Reservierung

Eine Reservierung ist eine lokale Konsistenzentscheidung von StockItem. Der Handler lädt genau ein Aggregate, ruft reserve auf und speichert die neue Version. Der spätere Repository-Adapter muss optimistische oder pessimistische Konkurrenzkontrolle umsetzen. Der Application Layer entscheidet nicht selbst, ob Bestand genügt.

Idempotenz

ReservationId ist der Idempotenzschlüssel. Derselbe Schlüssel mit derselben Bestellung und Menge bleibt wirkungslos wiederholbar. Derselbe Schlüssel mit anderem Inhalt wird vom Aggregate abgelehnt. Dadurch funktioniert dieselbe Regel für HTTP-Wiederholungen, Consumer-Retries und Process-Manager-Wiederanläufe.

Eventgrenze

InventoryEventPublisher erhält ausschließlich Domain Events des Inventory Contexts. Eine Übersetzung in veröffentlichte Integration Events gehört in den späteren Integrationsadapter, nicht in die Aggregate Root.

Payment Application

Zahlungsanforderung

RequestPaymentHandler erzeugt eine Payment Aggregate Root idempotent über PaymentReference. Betrag und Auftragsreferenz werden unveränderlich festgelegt. Eine widersprüchliche Wiederholung wird als Application-Konflikt abgelehnt.

Dreiphasige Autorisierung

Die Provider-Autorisierung wird absichtlich nicht innerhalb einer langen Datenbanktransaktion ausgeführt

1. Starttransaktion: Payment laden, Attempt starten, Zustand und Domain Event speichern.
2. Externer Aufruf: Gateway mit AttemptId als Idempotenzschlüssel aufrufen.
3. Abschlusstransaktion: Aggregate erneut laden, Ergebnis anwenden, Zustand und Domain Events speichern.

Dieses Muster reduziert Locks während Netzwerk-I/O und erlaubt Wiederanlauf nach Prozessabbruch. Ist ein Attempt bereits abgeschlossen, wird der Provider nicht erneut aufgerufen. Ist ein Attempt gestartet, aber noch nicht abgeschlossen, darf derselbe idempotente Provider-Aufruf wiederholt werden.

Ergebnisübersetzung

Der Gateway Port liefert ausschließlich drei fachlich relevante Ergebnisarten: autorisiert, fachlich abgelehnt oder technisch fehlgeschlagen. Provider-spezifische Protokolldetails bleiben im Adapter.

Abgrenzung

Die maximale Zahl der Versuche und terminale Zustände gehören zum Payment Aggregate. Die Reihenfolge aus Starttransaktion, Provider-I/O und Abschlusstransaktion gehört zum Application Service.

Ports, Transaktionen und Rückverfolgbarkeit

Eingangs- und Ausgangsports

Application Service Facades und Handler bilden die Eingangsseite. Repository, Clock, Transaction Boundary, Event Publisher und Payment Gateway bilden die Ausgangsseite. Kein Application-Modul kennt Spring, JPA, Kafka, HTTP oder einen konkreten Zahlungsprovider.

Transaktionsregel

Die lokale atomare Einheit umfasst Aggregate laden, fachliche Operation, Aggregate speichern und Domain Events in eine Outbox überführen. Ein direkter Broker-Publish innerhalb des Handlers wäre unzulässig, weil Datenbankcommit und Brokerbestätigung nicht atomar gekoppelt wären.

Context-Isolation

Ordering Application importiert nur Ordering Domain. Inventory Application importiert nur Inventory Domain. Payment Application importiert nur Payment Domain. ArchUnit-Fitness-Functions sichern diese Regel zusätzlich ab.

Rückverfolgbarkeit

10 Commands, 3 Queries, 13 Handler, 13 contextlokale Ports und 3 Application Service Facades sind den drei Bounded Contexts zugeordnet. Drei ausführbare Java-21-Smoke-Tests prüfen den vollständigen Ablauf ohne Framework.

Nächster Schritt

verbindet die Contexts über Domain- und Integration-Events, Outbox, Anti-Corruption Layer und einen Process Manager. Direkte Application-zu-Application-Aufrufe bleiben verboten.

Kontextintegration und Zuverlässigkeit

Ziel

Die drei fachlichen Kontexte Ordering, Inventory und Payment bleiben getrennte Konsistenz- und Sprachräume. Ihre Zusammenarbeit erfolgt ausschließlich über versionierte Integration Events, öffentliche Commands und einen eigenständigen Process Manager.

Integrationsprinzipien

• Domain Events bleiben innerhalb des erzeugenden Bounded Contexts.
• Integration Events bilden eine stabile Published Language.
• Übersetzer sind die einzige Stelle, an der interne Fachtypen in externe Verträge überführt werden.
• Jeder Context schreibt seine Outbox in derselben lokalen Transaktion wie seinen Fachzustand.
• Brokerzustellung ist mindestens einmal; Consumer müssen idempotent sein.
• Kein verteilter Datenbank-Commit verbindet die Kontexte.

Module

Domain Events und Integration Events

Unterschied

Ein Domain Event beschreibt eine bereits eingetretene fachliche Änderung in der Sprache eines Bounded Contexts. Ein Integration Event ist ein bewusst gestalteter, versionierter Vertrag für andere Kontexte. Beide dürfen nicht als derselbe Typ behandelt werden.

Übersetzung

Ereignisumschlag

Jeder Vertrag trägt Ereignis-ID, Typ, Schema-Version, Zeitpunkt, Korrelations-ID und Kausalitäts-ID. Dadurch bleiben Ablauf, Wiederholung und Diagnose nachvollziehbar.

Transactional Outbox und Inbox

Producer-Seite

Der Fachzustand und die Outbox-Nachricht werden in derselben lokalen Transaktion gespeichert. Ein Polling Publisher beansprucht offene Nachrichten, sendet sie an den Broker und markiert sie erst nach erfolgreicher Übergabe.

Consumer-Seite

Vor der Fachaktion prüft der Consumer seine Inbox anhand von Consumername und Ereignis-ID. Bereits verarbeitete Zustellungen werden ohne erneute Fachwirkung bestätigt.

Garantien

• keine verlorene Nachricht zwischen Fach-Commit und Broker-Publish
• mindestens einmal statt scheinbarer Genau-einmal-Zustellung
• idempotente Verarbeitung als fachliche Pflicht
• Wiederanlauf nach Prozess- oder Brokerfehler
• Reihenfolge pro Aggregat über einen stabilen Nachrichtenschlüssel

Anti-Corruption Layer

Zweck

Die Anti-Corruption Layer verhindert, dass Ordering-, Inventory- oder Payment-Typen in einem fremden Context zum gemeinsamen Modell werden. Sie übersetzt Bedeutung, Identitäten, Geldwerte und Fehler bewusst in die Published Language.

Regeln

1. Kein Integration Contract importiert Domain- oder Application-Klassen.
2. Kein Process Manager importiert fremde Aggregate.
3. Jede semantische Umbenennung wird im Übersetzer sichtbar.
4. Contextinterne Ereignisse dürfen unabhängig weiterentwickelt werden, solange der veröffentlichte Vertrag eingehalten wird.
5. Breaking Changes erzeugen eine neue Vertragsversion statt stiller Bedeutungsänderung.

Order Fulfillment Process Manager

Ablauf

1. OrderPlacedV1 startet den Workflow.
2. Der Process Manager fordert eine Bestandsreservierung an.
3. InventoryReservedV1 löst die Zahlungsanforderung aus.
4. PaymentAuthorizedV1 beendet den Workflow erfolgreich.
5. PaymentRejectedV1 löst Freigabe der Reservierung und Stornierung der Bestellung aus.
6. Ein technischer Zahlungsfehler kann als PaymentRetryScheduledV1 ohne sofortige Kompensation weitergeführt werden.

Zustandsverantwortung

Der Process Manager speichert nur contextübergreifenden: Bestellreferenz, Korrelations-ID, Reservierungsreferenz, Zahlungsreferenz, Status und bereits verarbeitete Ereignis-IDs. Er besitzt weder Order-, StockItem- noch Payment-Aggregate.

Saga-Kompensation

Kompensation ist eine neue fachliche Aktion und kein technisches Rollback über mehrere Datenbanken. Bei endgültiger Zahlungsablehnung werden Freigabe und Stornierung explizit befohlen und als eigener Ablauf beobachtet.

Versionierung, Idempotenz und Konsistenz

Versionierung

Die Schema-Version ist Bestandteil jedes Integration Events. Additive optionale Felder bleiben innerhalb einer Version kompatibel. Entfernte Felder, geänderte Semantik oder andere Datentypen benötigen einen neuen Vertrag.

Idempotenz

• Producer vergeben global eindeutige Ereignis-IDs.
• Inbox-Schlüssel bestehen aus Consumername und Ereignis-ID.
• Der Process Manager führt zusätzlich verarbeitete IDs im Workflowzustand.
• Commands besitzen fachliche Korrelations- und Kausalitätsinformationen.

Eventual Consistency

Nach dem lokalen Commit kann ein nachgelagerter Context zeitlich verzögert reagieren. APIs und Oberflächen müssen Zwischenzustände sichtbar machen. Ein Workflow ist erst nach dem abschließenden Integration Event erfolgreich oder endgültig fehlgeschlagen.

Kontextintegrations-Nachweis

Umgesetzte Bausteine

DDD-Gesamtwerk

Die DDD-Variante umfasst fachliche Erkundung, Ubiquitous Language, Subdomains, Bounded Contexts, Context Map, Value Objects, Aggregate, Application Layer, Ports und belastbare Kontextintegration.