Der Bounded Context ist das Zentrum des Strategic Designs im Domain-driven Design und lässt sich grob als abgegrenzter Bereich übersetzen.
Definition und Vorteile
Unter Bounded Context versteht man den Geltungsbereich einer Fachdomäne in Form ihres Datenmodells, ihrer Begrifflichkeiten und der sie ausmachenden Personen. Die Unterteilung eines komplizierten Gesamtsystems in Bounded Contexts macht die einzelnen Domänen greifbarer und überschaubarer. Ein Bounded Context definiert Verantwortlichkeiten, die Rechte und Pflichten, einer Domäne. Änderungen innerhalb eines Bounded Contexts sind überschaubarer umzusetzen, als Änderungen in einem riesigen Gesamtsystem ohne klare Trennungen. Zwischen verschiedenen Bounded Contexts gibt es sowohl gemeinsame als auch gänzlich unterschiedliche Konzepte.
Die Abbildung zeigt zwei exemplarische Bounded Contexts, den Einkauf und den Verkauf. In beiden Bounded Contexts gibt es sowohl augenscheinlich gemeinsame Konzepte (Adresse), unterschiedliche Konzepte unter dem gleichen Namen (Artikel) als auch voneinander völlig unabhängige Konzepte (Wareneingang und Kundenbestellung). Der Bounded Context sorgt für Klarheit. Ist von einem Artikel im Bounded Context Einkauf die Rede, so ist unmissverständlich, welche Sicht auf den Artikel gemeint ist. Auch schafft der Begriff selbst Klarheit. Wäre diese Klarheit nicht gegeben, so könnten einige Gewerke von einem Artikel sprechen, andere wiederum von einem Produkt und der Software-Entwickler würde aus Sicht des Quellcodes vielleicht den Begriff Item benutzen. Diese sprachliche Klarheit im Domain-driven Design wird auch als Ubiquitous Language bezeichnet.
Ubiqitous Language
Die allgegenwärtige Sprache, wie sich der Begriff wohl am besten ins Deutsche übersetzen lässt, schafft ein gemeinsames Verständnis für Fachbereiche und Software-Entwickler. Dieses ist fundamental für die erfolgreiche Umsetzung komplizierter Geschäftslogik in Software, denn sie bringt Klarheit und vermeidet Ungenauigkeiten, Widersprüche und Missverständnisse.
Aus meiner Sicht ist es extrem wichtig, gemeinsame Begrifflichkeiten festzulegen und (am besten in einem Glossar) klar zu definieren, denn ansonsten passiert es oft, dass in den Köpfen der Beteiligten völlig unterschiedliche Vorstellungen davon herrschen, was einen Begriff ausmacht. Ich empfehle daher auch dringend, die Sprache der Domäne im Code zu verwenden und nicht beispielsweise vom Deutschen ins Englische zu übersetzen. Dabei ist zwischen technischen und fachlichen Begriffen zu differenzieren. Es ist nicht sinnvoll, Getter und Setter, oder Patterns wie Factory ins Deutsche zu übersetzen. Handelt es sich aber beim Abschließen eines Auftrags um einen etablierten Begriff aus der Domäne, der bekannte fachliche Implikationen hat, so würde ich diesen Begriff auch direkt im Code verwenden und nicht etwa mit complete übersetzen.
Bounded Contexts und Servicearchitektur
Domain-driven Design und Bounded Contexts lassen sich sowohl mit einem monolithischen als auch Microservice-Ansatz wunderbar umsetzen. Die Kommunikation über Bounded Contexts hinweg kann über Domain Events, der Transport für serviceübergreifende Kommunikation über asynchrone Wege wie einen Message Broker realisiert werden. Es empfiehlt sich, dass ein Bounded Context immer nur durch ein Team verantwortet wird. Umgekehrt kann ein Team aber durchaus mehrere Bounded Contexts verantworten.
Domain-driven Design lässt sich hervorragend mit dem Ansatz der hexagonalen Architektur kombinieren. Mit konsequenter Verwendung der Ubiquitous Language im Quellcode kann erreicht werden, dass die Domain in einem nach hexagonaler Architektur gestaltetem Service für den Fachbereich lesbar und nachvollziehbar ist. Auch die dazugehörigen Unit-Tests sollten für die Domänenexperten lesbar sein, da sie damit automatisch als fachliche Spezifikationen dienen können und letzlich der ultimative Beleg dafür sind, ob die Software-Entwickler die Domäne vollends durchdringen oder nicht.
Leider habe ich noch nie erlebt, dass vor einem anstehenden technischen Migrationsprojekt eine saubere, technikfreie Abbildung der Domäne als Quellcode vorlag. In so einigen Fällen, die ich miterlebt habe, hätte dies einen unschätzbaren Mehrwert bedeutet, denn man hätte nicht auf der grünen Wiese anfangen und den Software-Entwicklern die Domäne anhand von teilweiser veralteter und lückenhafter Dokumentation und mündlichen Informationen einzelner Wissensträger vermitteln müssen, sondern einfach nur die Technik um die Fachlichkeit herum erneuert. Natürlich ist dies immer noch keine triviale Aufgabe und allein der richtige Schnitt kann maßgeblich zum Erfolg oder Misserfolg einer Microservice-Migration beitragen, aber seien wir ehrlich: Die Vorstellung, einen sauber nach hexagonaler Architektur strukturierten Monolithen in Microservices zu zerlegen, ist eine deutlich überschaubarere und weitaus weniger komplexe Aufgabe, als komplett bei null zu beginnen und sich alle Abläufe aus Dokumentation, Gesprächen und Reverse Engineering ableiten zu müssen.