Context Is King

Abgesehen von der trivialsten Software bewegen sich die meisten Anwendungen in einem mehr oder weniger komplexen Problemumfeld (Domäne). Bevor man nicht weiß, welche Bereiche mit welchen Verantwortlichkeiten existieren, in welchen Umgebungen man sich bewegt und welches Problem sie eigentlich lösen sollen, macht es keinen Sinn über Architekturen, Datenformate, Datenstrukturen, Frameworks oder Lösungsansätze nachzudenken.

Deshalb sind die maßgeblichen Voraussetzungen für DDD (oder generell komplexen Anwendungen, die auch damit umgesetzt werden sollen) Bounded Context und Context Map.
Erst dann kann man sich Gedanken über Objekte und Strukturen machen.

Vorab eine knappe Begriffserklärung:
Context: spezifischer Verantwortungsbereich
Bounded Context (BC): die klar definierte Umgebung und Grenzen einer Problemdomäne
Context Map: eine „Landkarte“ mit allen BCs der Domäne


Am Beispiel eines Unternehmens das sich mit Softwareentwicklung beschäftigt, möchte ich die Begriffe näher erklären. Ein Hauptprodukt des Unternehmens ist eine komplexe B2B-Anwendung.

Das Unternehmen besteht aus den Bereichen Entwicklung, Buchhaltung, Backoffice, Datenmanagement und Projektleitung. Jeder Bereich hat seine eigen interne Organisation, Regeln, Ressourcen und Informationseinheiten.

Die Entwicklung selbst kann noch in weitere Kontexte unterteilt sein: Frontend, Backend, DevOps. Auch hier gelten die gleichen Regeln der Grenzen und Verantwortungen.

Findet das Backoffice einen Fehler in der Anwendung, ändert es nicht den Code direkt. Das wäre eine Überschreitung ihrer Grenzen und Verantwortlichkeiten. Umgekehrt kann kein Entwickler in die Lohnbuchhaltung reinschauen. Sie kommunizieren miteinander und geben die Informationen weiter oder halten sie zurück, ohne ihre interne Organisation preiszugeben.

Im Falle eines Bugs kann das Backoffice zum IT-Leiter Paul gehen und es berichten. Er entscheidet dann ob und wie der Fehler behoben wird. Er sagt auch, in welcher Form er etwas berichtet haben will („Das ist ein Fehler in X“ wird gleich zurückgewiesen…). Alles geht über ihn und nichts an ihm vorbei in die Entwicklung – er ist das Schutzschild (im DDD-Jargon ein Anti Corruption Layer [ACL]) zur Abteilung Entwicklung.


In praktisch jeder nicht-trivialen Domäne oder Anwendung sind mehrere Modelle im Spiel.
Deshalb ist es wichtig, Grenzen zu setzen, in denen die einzelnen Modelle eine eindeutige Aussage und Struktur haben und verstanden werden. Es muss klar sein, was man lösen will, wo die Grenzen liegen und wie man miteinander kommuniziert.

Anders gesagt:
Ein Bounded Context ist „… eine Umgebung, in der die Bedeutung eines Wortes oder einer Aussage eindeutig ist“ [Evans, 2003]

Jeder BC ist eine (möglichst) autonome Komponente, BC 1 weiß nichts über die Innereien von BC 2, sie kommunizieren über einfache Informationsstrukturen miteinander, die sie dann oft für ihre eigenen Zwecke übersetzen. Natürlich kann ein BC von einem anderen abhängig sein (welchen Sinn macht es einen Versand zu haben, wenn ich keine Produkte verkaufe?) – aber nur abstrakt, niemals in der eigentlichen Implementierung.

Jeder Context behält stets die Hoheit über seine Ressourcen (möglichst auch eine eigene Datenhaltung!).

In jedem BC gibt es mindestens ein Domain Model. In der Abteilung Entwicklung aus dem obigen Beispiel ist das bspw. ein Programmierer, ein Designer, ein Business Analyst, ein Serversystem usw. Modelle aus verschiedenen BC benutzen häufig gleiche Begriffe, doch sie haben in jedem Context einen andere Bedeutung und Ausprägung

Ein BC ist kein physisches Artefakt, es ist eine explizite und sprachliche Begrenzung.

Jeder BC besitzt mindestens ein eigenständiges Model und seine eigene unmissverständliche Sprache (Ubiquitous Language).
Jedes Model in einem BC kann beliebig nach Bedarf implementiert werden. So kann z.B. die reine Verwaltung von Daten in BC 1 mit profanem CRUD gelöst sein und ein anderes Model in BC 2 CQRS und Event Sourcing benutzen und ein weiterer BC 3 noch nicht mal DDD oder gar OOP benutzen.

Software ist ausführbares Wissen – ohne Kontext gibt es keine vernünftige Kommunikation.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation