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? Passen Microservices und Bounded Contexts wie Topf und Deckel zusammen oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?

Bounded Context und Ubiquitous Language

Domain Driven Design (DDD) 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 als Vokabular angewendet wird. In den meisten Fällen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenhängen (z. B. Fach-Abteilungen) andere Bedeutungen haben. Im Domain Driven Design (DDD) 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 eindeutige Bedeutung hat. Dieser abgegrenzte „Sprachraum“ ist der Bounded Context.

Ein Bounded Context ist kein Microservice

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. Es ist aber deutlich zu sagen: Ein Bounded Context ist kein Microservice. Ein Microservice ist technisch und stelle eine Deployment Grenze dar. Ein Bounded Context ist dagegen eine fachliche Sprachgrenze mit einer klaren Definition für jeden Begriff. Die Größe und Form eines solchen Contexts wird durch die strategische Planung, die Komplexität des Modells und die Teamstruktur bestimmt.

Bounded Contexts sind 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.

Das richtige Werkzeug für den Einsatz von DDD und Microservices

Die DDD bietet einen ganzen Baukasten an Werkzeugen an, um strategisches und taktisches Domain Driven Design zu betrieben. Beim strategischen DDD sind das z. B. Dave Snowdens  Komplexitätsanalyse nach Cynefin, Domänenmodelllierung mit Aberto Brandolinis Event Storming, Exploration mit Hilfe von Simon Wardleys Wardley Mapping, Strategische Entkopplung durch Eric Evans Bounded Context Mapping oder System Thinking nach Donella Meadows. Diese Werkzeuge zu kennen und erfolgreich einzusetzen ist essenziell für den erfolgreichen Einsatz DDD und Microservices.

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.

Fazit

Anhand dieser Betrachtungen lässt sich klar sagen: Auf der Ebene von Microservices und Domain Driven Design passt der Deckel ganz klar auf den Topf! Bounded Contexts sind für diesen Bund ein wertvoller Beitrag – unter vielen anderen.

Sie möchten mehr zu dem Thema erfahren?

Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermitteln die beiden Trainings „Flexible Architekturmodelle (FLEX)“ und „Domain Driven Design (DDD)“. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem perfekten Trainings-Doppelpack Credit Points in den Kompetenzbereichen Technik, Methodik und Kommunikation.