Microservices und Domain Driven Design (DDD) zählen nach wie vor zu den Hype-Themen der IT-Szene. Ein paar Sekunden Google-Suche reichen aus, um gleich dutzende Artikel ausfindig zu machen, die wahre Loblieder auf die „Liebesbeziehung“ von Microservices und Bounded Contexts singen. Aber ist das wirklich so? Bilden Microservices und Bounded Contexts die perfekte Ehe oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?

Domain Driven Design ist als ein Konzept entstanden, um die Distanz zwischen den Domänen-Experten und dem Software-Entwicklungsteam und die daraus resultierenden Projektrisiken nachhaltig zu verringern. Eric Evans hat das in seinem Standardwerk „Domain-Driven Design: Tackling Complexity in the Heart of Software“ präzise beschrieben. Ein zentrales Element ist dabei eine gemeinsame Fachsprache, die „Ubiquitous Language“, die aus der Domänen-Story entwickelt und auf allen Ebenen, vom Grobkonzept bis in den Quellcode hinein, angewendet wird. In den meisten Fällen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenhängen (z.B. Abteilungen) andere Bedeutungen haben. Im Domain Driven Design wird in diesem Fall keine sprachliche Lösung geschaffen, sondern eine Grenze um den maximalen Raum innerhalb der Domäne gezogen, in dem jeder Fachbegriff eine einzige, eindeutige Bedeutung hat. Dieser abgegrenzte „Sprachraum“ ist der Bounded Context.

Aus dieser Perspektive wird klar, dass ein Bounded Context – je nach Komplexität der Domäne – ganz unterschiedliche Dimensionen annehmen kann. Die Spanne erstreckt sich von einem sehr kleinen Kontext, der sich durchaus zur Abgrenzung eines Microservice eignen kann, bis hin zu einem gewaltigen, als Microservice untauglichen Kontext-Monolithen. In den meisten Fällen sind Microservice und Bounded Context folglich ein ausgesprochen ungleiches Paar. Der Bounded Context beschreibt die maximale Ausdehnung, die ein Microservice logisch annehmen kann und steht damit geradezu im Widerspruch zu dessen Anforderungen an reduzierte Komplexität und Größe.

Woher rührt dann also der Hype? Nun, zum einen sind Bounded Contexts eine Möglichkeit, erste Schnitte im Projekt anzusetzen und bieten damit zumindest eine Annäherung. Zum anderen ist jeder Bounded Context ein Cluster, in dem mehrere zu definierende (Micro-)Services durch die Ubiquitous Language logisch verbunden sind. Auch das kann bis hin zur Evolution der Microservice-Landschaft eine Menge Vorteile bringen.

Für die Microservices selbst und deren Abgrenzung stellt Domain Driven Design das Konzept der internen Bausteine (Internal Building Blocks) mit vielen nützlichen Patterns zur Verfügung. Das vielleicht wichtigste dabei sind die Aggregates, die als kleinste sinnvolle Einheit für einen Microservice sozusagen den Gegenpol zu den Bounded Contexts bilden.

Anhand dieser Betrachtungen lassen sich die Ausgangsfragen klar beantworten: „Die perfekte Ehe“ lässt sich auf der Ebene von Microservices und Domain Driven Design schließen. Bounded Contexts sind für diesen Bund ein wertvoller Beitrag – unter vielen anderen.

Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermittelt das Trainings-Doppelpack „Flexible Architekturmodelle (FLEX)“ und „Domain Driven Design (DDD)“ der ITech Academy.

Weiterführende Links:
Training „iSAQB Domain Driven Design (DDD)“
Training „iSAQB Flexible Architekturmodelle (FLEX)“

 


Bildrechte (Montage):
Halfaral [CC BY-SA 3.0], von Wikimedia Commons