Fachliche Erkundung

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.

• 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.

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.

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.

• 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?

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.