Systemgrenzen und DDD: Wenn „Kunde“ zweimal etwas anderes bedeutet
Ein Kunde ist inaktiv. Im Vertrieb ist das eine einfache Aussage: Die Geschäftsbeziehung ist beendet. In der Abrechnung steht allerdings noch eine Schlussrechnung aus. Dort muss derselbe Kunde weiterhin verarbeitet werden können.
Stell dir vor, beide Bereiche verwenden ein gemeinsames Statusfeld. Der Vertrieb setzt es auf „inaktiv“. Die Abrechnung interpretiert denselben Wert als „keine Rechnung mehr erstellen“. Die Schnittstelle hat den Wert korrekt übertragen. Trotzdem entsteht ein Fehler im Ablauf.
Hier beginnt eine typische Frage des Domain-Driven Design, kurz DDD: In welchem fachlichen Zusammenhang gilt ein Modell? Ein Bounded Context macht diesen Gültigkeitsbereich ausdrücklich. Das hilft, unterschiedliche Bedeutungen zu erkennen und ihre Verbindung bewusst zu gestalten.
Ein zusätzliches Statusfeld scheint erst einmal zu reichen
Das Team könnte „inaktiv, aber noch abzurechnen“ ergänzen. Für den aktuellen Fall wäre damit etwas gewonnen. Beim nächsten Gespräch kommt eine weitere Situation hinzu: Ein Kunde hat mehrere Verträge. Einer endet, ein anderer läuft weiter. Was soll der gemeinsame Kundenstatus jetzt aussagen?
Ihr könnt die Liste erweitern. Dabei beginnt ein Feld zunehmend mehrere Fragen zu tragen: Besteht eine Geschäftsbeziehung? Gibt es laufende Verträge? Darf eine Rechnung erstellt werden? Ist das Abrechnungskonto gesperrt?
Die beteiligten Menschen sind sich über die Wirklichkeit womöglich weitgehend einig. Sie brauchen lediglich unterschiedliche Ausschnitte davon für ihre Arbeit. Der Vertrieb beurteilt die Beziehung. Die Abrechnung muss konkrete Leistungen und die Voraussetzungen ihrer Verarbeitung kennen.
Das Gespräch wird einfacher, wenn ihr euch echte Vorgänge zeigen lasst. Wann setzt der Vertrieb den Status? Welche Handlung hängt daran? Unter welchen Bedingungen hält die Abrechnung einen Vorgang zurück? An diesen Regeln erkennt ihr, ob nur ein missverständlicher Name vorliegt oder tatsächlich verschiedene Modelle gebraucht werden.
Bounded Contexts geben einem Modell einen Geltungsbereich
Im Strategic Design von DDD begrenzt ein Bounded Context den Bereich, in dem ein Modell konsistent gilt. Innerhalb dieses Zusammenhangs arbeiten Fachleute und Entwicklung an einer gemeinsamen Ubiquitous Language: Begriffe und Bedeutungen, die auch das Softwaremodell prägen. Eric Evans beschreibt diese Konzepte in seiner DDD Reference.
Im Beispiel könntet ihr im Vertrieb präzise von einer beendeten Geschäftsbeziehung sprechen. Die Abrechnung beschreibt dagegen die Freigabe eines konkreten Abrechnungsvorgangs. Beide Aussagen dürfen nebeneinander bestehen. Ihr müsst ihre Bedeutung nur so festhalten, dass sie in Code, Schnittstelle und Gespräch zusammenpasst.
Eine abweichende Bezeichnung allein verlangt noch keinen neuen Bounded Context. Vielleicht lässt sich das Problem bereits durch präzisere Begriffe im selben Modell lösen. Die Grenze wird interessant, wenn verschiedene Regeln, Verantwortungen und Änderungsbedürfnisse ein gemeinsames Modell dauerhaft widersprüchlich oder unnötig schwer machen.
Für die Klärung braucht ihr zunächst ein paar konkrete Fälle und die Menschen, die ihre Regeln kennen. Das technische Vokabular hilft euch, die erkannte Unterscheidung zu benennen. Ihr könnt diese Arbeit beginnen, bevor ihr jede Vertiefung des DDD kennengelernt habt.
Die Verbindung zwischen den Modellen braucht eine eigene Aussage
Getrennte Bedeutungen lösen noch nicht den Austausch. Die Abrechnung muss weiterhin erfahren, dass ein Vertrag beendet wurde. Sie soll daraus nur keine pauschale Sperre aller Rechnungen ableiten.
Ihr beschreibt deshalb genauer, was die Schnittstelle übermittelt: Für welchen Kunden endet welcher Vertrag zu welchem Zeitpunkt? Die Abrechnung kann diese Information in ihrem Modell verwenden und nach ihren Regeln klären, welche Leistungen noch abzurechnen sind.
Eine gemeinsame Kundenkennung bleibt dabei nützlich. Sie verbindet Identitäten. Aus ihr folgt jedoch nicht, dass beide Bereiche denselben Lebenszyklus oder dieselbe Statuslogik besitzen müssen. Ihr könnt dieselbe Person oder Firma referenzieren und ihre fachliche Bedeutung unterschiedlich modellieren.
Context Mapping beschreibt die Beziehungen zwischen Bounded Contexts. Es macht damit auch die Übergänge zwischen Modellen zum Gegenstand der Gestaltung. Martin Fowler ordnet diese Aufgabe in seiner Erklärung zu Bounded Contexts ein.
Für euren Übergang braucht ihr eine überprüfbare Vereinbarung: Welches Ereignis oder welcher Zustand wird übermittelt? Welcher Bereich bestimmt seine Bedeutung? Wie werden Korrekturen und verspätete Informationen behandelt? Und wer muss einbezogen werden, bevor diese Aussage verändert wird?
Die Übersetzung lässt sich an dem Fall prüfen, der den Konflikt ausgelöst hat. Die Geschäftsbeziehung endet, die Schlussrechnung bleibt möglich. Ergänzend prüft ihr den Kunden mit mehreren Verträgen. So bekommt die Grenze eine fachliche Begründung, die über die Vorliebe für einen bestimmten Architekturstil hinausgeht.
Eine fachliche Grenze legt das Deployment noch nicht fest
An diesem Punkt kommt oft die technische Anschlussfrage: Brauchen Vertrieb und Abrechnung jetzt eigene Microservices?
Aus der geklärten Bedeutung ergibt sich diese Entscheidung noch nicht. Eine fachliche Trennung kann innerhalb einer Anwendung organisiert sein. Getrennt bereitgestellte Dienste können umgekehrt weiterhin eng an demselben unklaren Statusmodell hängen. Dann bleibt der ursprüngliche Konflikt trotz getrennter Deployments bestehen.
Ihr könnt im Beispiel drei Fragen unabhängig beantworten. Wo gelten die Regeln für eine Geschäftsbeziehung? Welche Softwareteile lassen sich eigenständig bereitstellen? Wer kann eine Änderung der Schnittstelle tatsächlich entscheiden und umsetzen?
Diese Grenzen können zusammenpassen. Wenn sie auseinanderliegen, sollte das in eurem Arbeitsbild erkennbar sein. Vielleicht betreibt dasselbe Team beide Bereiche, während unterschiedliche Fachverantwortliche ihre Regeln bestimmen. Vielleicht liegen zwei Module im selben Deployment, brauchen aber getrennte Zuständigkeiten für Änderungen.
Wie ihr solche Unterschiede verständlich darstellt, ist eine weitere Frage. Der Artikel über Systemmodelle mit C4 und arc42 zeigt, wie verschiedene Sichten dabei helfen, ohne alle Informationen in eine einzige Zeichnung zu zwingen.
Jemand muss die Bedeutung auch im Alltag schützen können
Selbst die genauere Schnittstelle bleibt anfällig, wenn jeder Bereich ihre Felder nach Belieben umdeuten darf. Zur fachlichen Klärung gehört deshalb gelebte Verantwortung: Wer kennt die Regeln, wer darf sie ändern, und wer kann erkennen, dass eine andere Nutzung betroffen ist?
Hier liegt die Verbindung zur Lektion „Verantwortungen schneiden“ im Modul „Stabilität herstellen“ von THINK FIRST Individual. Sie beschäftigt sich mit tatsächlicher Verantwortung im System. Das unterstützt die Arbeit an solchen Übergängen; die spezialisierten DDD-Konzepte vertiefst du über die genannten Fachquellen.
Zurück zur Schlussrechnung. Das Team muss jetzt keinen universellen Kundenstatus erfinden, der jede denkbare Lage ausdrückt. Der Vertrieb kann eine Geschäftsbeziehung beenden. Die Abrechnung kann die verbleibenden Leistungen verarbeiten. Beide wissen, welche Information sie austauschen und welche Entscheidung im eigenen Bereich liegt.
Die Verbesserung zeigt sich in einem gewöhnlichen Vorgang, der wieder verständlich geworden ist. Genau dort bewährt sich eine fachliche Grenze: Die Menschen können erklären, was eine Aussage bedeutet, wo sie gilt und was an ihrem Übergang geschehen muss.