Strategisches Domain-Driven Design: Bounded Contexts und Context Maps

Warum Domain-Driven Design in ein Kapitel über Struktur gehört

Jeder Stil in diesem Kapitel braucht Grenzen. Ein modularer Monolith braucht Modulgrenzen; die Microservices aus Kapitel 6 brauchen Servicegrenzen; selbst eine hexagonale Anwendung muss wissen, was in das Hexagon gehört. Domain-Driven Design (DDD) ist die am weitesten verbreitete Methode, diese Grenzen in der Fachdomäne selbst zu finden statt in technischen Schichten.

Eric Evans führte es in Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003) ein. Sein Argument: In den meisten Geschäftsanwendungen liegen die schwierigsten Probleme nicht in der Technik, sondern im Verständnis der Domäne, also darin, was eine Police, ein Schadensfall, eine Lieferung oder eine Erstattung wirklich ist und welche Regeln dafür gelten. Software sollte daher um ein bewusst gestaltetes Modell der Domäne herum gebaut werden, das Entwicklungsteams und Fachexperten gemeinsam entwickeln, und dieses Modell sollte vor der Vermischung mit anderen Modellen geschützt werden. 2015 veröffentlichte Evans eine kurze DDD Reference, die die Muster zusammenfasst und einige ergänzt, etwa Partnership und Big Ball of Mud als Context-Map-Muster sowie Domain Events als Baustein.

DDD hat zwei Hälften. Strategisches Design teilt eine große Domäne in Subdomänen und Bounded Contexts auf und bildet die Beziehungen zwischen ihnen ab; das ist Architektur und das Hauptthema hier. Taktisches Design liefert Bausteine (Entitäten, Value Objects, Aggregate und andere), um das Modell innerhalb eines Kontexts zu schreiben; das ist Design und wird kurz behandelt.

Ubiquitous Language

Eine Ubiquitous Language ist ein gemeinsames Vokabular, das Entwicklungsteams und Fachexperten zusammen aufbauen und das in Gesprächen, Dokumenten, Tests und Code konsistent verwendet wird. Wenn die Disponenten sagen, ein Kurier sei „gestapelt“, wenn er zwei Bestellungen aus demselben Restaurant fährt, dann heißt es im Code stack, nicht multiOrderAssignment. Erweist sich ein Begriff als mehrdeutig oder sperrig, ändert das Team Sprache und Code gemeinsam.

Das klingt nach einer Frage der Benennung, hat aber architektonische Folgen. Die Übersetzung zwischen den Worten des Geschäfts und den Worten des Codes ist der Ort, an dem Missverständnisse und damit Fehler entstehen. Und sobald zwei Gruppen dasselbe Wort mit unterschiedlicher Bedeutung verwenden, haben Sie einen Hinweis auf zwei verschiedene Modelle gefunden, und genau das ist der Ausgangspunkt für Bounded Contexts.

Subdomänen: Core, Supporting und generisch

Die Fachdomäne als Ganzes gliedert sich in Subdomänen: Tätigkeitsbereiche wie Speisekarten, Bestellungen, Zahlungen und Disposition. Fachleute ordnen sie drei Arten zu und bauen dabei auf Evans’ Unterscheidung zwischen Core Domain und generischen Subdomänen auf; die Dreiteilung mit Supporting Subdomains wurde von späteren Autoren populär gemacht, insbesondere von Vaughn Vernon in Implementing Domain-Driven Design (2013).

Die Core Domain ist das, was das Unternehmen von seinen Wettbewerbern unterscheidet, und der Grund, warum sich die Software zu bauen lohnt. Für ein Essenslieferunternehmen ist das wahrscheinlich die Disposition: Bestellungen Kurieren zuordnen und Ankunftszeiten vorhersagen. Eine Supporting Subdomain ist spezifisch für das Unternehmen und notwendig, aber keine Quelle von Vorteilen: Speisekartenverwaltung, Kurier-Onboarding. Eine generische Subdomäne ist ein Problem, das viele Unternehmen teilen und für das es gute vorhandene Lösungen gibt: Zahlungen, Identität, E-Mail und SMS.

Die Einordnung ist eine Investitionsentscheidung. Die Core Domain verdient die erfahrensten Leute, die sorgfältigste Modellierung und Code, der Ihnen vollständig gehört, denn dort wird bessere Software direkt zum Geschäftsvorteil. Supporting Subdomains verdienen solide, aber einfachere Designs, oft ein schlichtes Modul in Schichten. Generische Subdomänen sollten meist zugekauft, als Service genutzt oder als dünne Adapter über Open-Source-Komponenten gebaut werden: Einen eigenen Identity Provider zu bauen ist Aufwand an einer Stelle, an der Sie nicht gewinnen können. Die Einordnung ändert sich zudem mit der Zeit; eine unterstützende Fähigkeit kann zur Core Domain werden, wenn sich die Geschäftsstrategie ändert.

Bounded Contexts

Ein Bounded Context ist eine explizite Grenze, innerhalb derer ein Modell und eine Ubiquitous Language konsistent gelten. Innerhalb davon hat „Bestellung“ genau eine Bedeutung. Außerhalb kann dasselbe Wort etwas anderes bedeuten, und das ist in Ordnung, denn jedes Modell ist für einen Zweck gestaltet. Evans stellte fest, dass der Versuch, das Modell eines großen Systems zu einem einzigen zu vereinheitlichen, weder machbar noch wirtschaftlich ist; er bringt riesige gemeinsame Klassen hervor, die jedem Zweck schlecht dienen und die jedes Team ändern muss.

Subdomänen und Bounded Contexts sind verschiedene Dinge, auch wenn sie oft zusammenfallen. Eine Subdomäne ist Teil des Problems: Sie existiert im Unternehmen, ob es Software gibt oder nicht. Ein Bounded Context ist Teil der Lösung: eine Grenze, die Sie für ein Modell wählen, und meist auch für Code und Daten, die einem Team gehören. Ideal ist ein Bounded Context pro Subdomäne, doch in Altsystemen erstreckt sich oft ein Kontext über mehrere Subdomänen, und eine große Subdomäne kann mehrere Kontexte brauchen.

Context Maps

Eine Context Map zeigt die Bounded Contexts eines Systems und die Beziehungen zwischen ihnen. Die Beziehungen beschreiben sowohl die technische Integration als auch Macht und Kommunikation zwischen den Teams, weshalb es beim Context Mapping ebenso um Organisationen wie um Code geht. Es ist eine direkte Anwendung des Gesetzes von Conway: Die Map zeigt, wo die Kommunikationswege der Organisation und die Integrationswege des Systems übereinstimmen müssen.

Viele Beziehungen sind Upstream/Downstream: Die Entscheidungen des Upstream-Kontexts wirken sich auf den Downstream-Kontext aus, aber nicht umgekehrt. Das Downstream-Team hat dann die Wahl, wie es damit umgeht, und genau diese Wahl benennen die meisten Muster.

Zwei dieser Muster verdienen besondere Aufmerksamkeit. Ein Anticorruption Layer (ACL) ist eine Reihe von Adaptern und Übersetzern, die ein Downstream-Kontext baut, damit ein fremdes Modell, oft ein Altsystem oder ein externer Anbieter, nicht in sein eigenes Modell durchsickern kann. Es ist dieselbe Idee wie der getriebene Adapter aus Abschnitt 5.6, angewandt zwischen Kontexten, und die Standardwahl für die Integration mit allem, was Sie nicht kontrollieren. Ein Open Host Service zusammen mit einer Published Language ist der Weg des Upstream-Kontexts, viele Konsumenten gut zu bedienen: ein dokumentiertes, versioniertes Protokoll statt einer eigenen Integration für jeden. Ein Shared Kernel sollte klein bleiben; ein großer macht aus zwei Kontexten wieder einen, über den zwei Teams streiten, und Evans’ Referenz von 2015 ergänzt Big Ball of Mud als ehrliche Bezeichnung für einen Bereich ganz ohne klare Grenzen, der eingedämmt statt erweitert werden sollte.

Event Storming: die Kontexte entdecken

Grenzen werden mit Fachexperten entdeckt, nicht im Alleingang entworfen. Event Storming, von Alberto Brandolini entwickelt und 2013 erstmals in seinem Blog beschrieben, ist das beliebteste Workshopformat dafür. Die Menschen, die das Geschäft kennen, und die Menschen, die die Software bauen, stehen an einer langen Papierwand und schreiben Domain Events (Dinge, die passiert sind, in der Vergangenheitsform: Bestellung aufgegeben, Kurier zugewiesen, Essen abgeholt) auf orange Haftnotizen und ordnen sie auf einer Zeitleiste an.

Danach ergänzt die Gruppe die Commands, die Events auslösen, die beteiligten Personen und externen Systeme, die Policies, die auf Events reagieren („immer wenn eine Bestellung aufgegeben wird, einen Kurier finden“), und vor allem die Hotspots, an denen Uneinigkeit herrscht oder niemand Bescheid weiß. Gruppen von Events, die eine Sprache und einen Zweck teilen, deuten auf Bounded Contexts hin; Stellen, an denen dasselbe Wort unterschiedlich verwendet wird, deuten auf Grenzen hin; Stellen, an denen eine Übergabe stattfindet, deuten auf Integrationspunkte hin. Eine Big-Picture-Session für ein ganzes Unternehmen dauert ein oder zwei Tage und braucht kaum Vorbereitung außer den richtigen Leuten und viel Wandfläche.

Taktische Muster in Kürze

Innerhalb eines Bounded Context bietet DDD Bausteine für das Modell. Eine Entität hat eine Identität, die bestehen bleibt, während sich ihre Attribute ändern: Eine Bestellung ist dieselbe Bestellung, nachdem sich ihr Status geändert hat. Ein Value Object hat keine Identität und ist allein durch seine Werte definiert: Zwei Money(12.50, "GBP")-Objekte sind austauschbar, und Value Objects sind meist unveränderlich. Ein Domain Event hält etwas Bedeutsames fest, das in der Domäne passiert ist.

Ein Aggregat ist eine Gruppe von Entitäten und Value Objects, die für Änderungen als eine Einheit behandelt wird, mit einer Entität als Wurzel. Code von außen darf nur Referenzen auf die Wurzel halten und das Aggregat nur über sie ändern, damit die Wurzel die Invarianten des Aggregats durchsetzen kann (Regeln, die immer gelten müssen, etwa „nach dem Aufgeben einer Bestellung können keine Positionen mehr hinzugefügt werden“). Eine Transaktion sollte ein Aggregat ändern; andere Aggregate werden per ID referenziert und über Domain Events aktualisiert, was Aggregate zur natürlichen Einheit der Konsistenz und später der Verteilung macht. Ein Repository lädt und speichert ganze Aggregate und wirkt für die Domäne wie eine Collection; seine Schnittstelle ist in hexagonaler Sprache ein getriebener Port.

from dataclasses import dataclass, field
from decimal import Decimal

@dataclass(frozen=True)
class Money:                               # value object: equal if values equal
    amount: Decimal
    currency: str
    def __add__(self, other):
        if other.currency != self.currency:
            raise ValueError("currency mismatch")
        return Money(self.amount + other.amount, self.currency)
    def times(self, n: int):
        return Money(self.amount * n, self.currency)

@dataclass
class OrderLine:                           # entity inside the aggregate
    dish_id: str
    qty: int
    price: Money

@dataclass
class Order:                               # aggregate root
    id: str
    restaurant_id: str                     # other aggregates referenced by ID only
    lines: list[OrderLine] = field(default_factory=list)
    status: str = "draft"
    events: list = field(default_factory=list)

    def add(self, dish_id, qty, price):
        if self.status != "draft":
            raise ValueError("order already placed")    # invariant
        self.lines.append(OrderLine(dish_id, qty, price))

    def place(self, minimum: Money):
        total = Money(Decimal(0), minimum.currency)
        for line in self.lines:
            total = total + line.price.times(line.qty)
        if total.amount < minimum.amount:
            raise ValueError("below restaurant minimum")  # invariant
        self.status = "placed"
        self.events.append({"type": "OrderPlaced", "order_id": self.id, "total": str(total.amount)})

Das Beispiel hält das Aggregat klein, referenziert das Restaurant per ID, statt ein Restaurant-Objekt zu halten, und setzt seine Regeln in Methoden durch, statt sie den Aufrufern zu überlassen. Ein häufiger Fehler ist das Gegenteil: Aggregate, die so groß sind, dass jede Änderung eines Benutzers dieselben Zeilen sperrt, oder Domänenobjekte, die nur Sammlungen von Gettern und Settern sind, während die Regeln in Service-Klassen liegen (Martin Fowler nennt das das anämische Domänenmodell).

Bounded Contexts als Modul- und Servicegrenzen

Bounded Contexts sind der beste verfügbare Leitfaden dafür, wo Modulgrenzen in einem Monolithen und Servicegrenzen in einem verteilten System zu ziehen sind. Ein Kontext hat sein eigenes Modell, seine eigene Sprache, seine eigenen Daten und idealerweise ein verantwortliches Team, und genau diese Eigenschaften machen ein Modul kohäsiv und lose gekoppelt. In einem modularen Monolithen wird jeder Kontext zu einem Modul mit eigenem Schema; darin hält die hexagonale Struktur aus Abschnitt 5.6 das Modell unabhängig von der Infrastruktur.

Muss ein Kontext später separat deployt werden, hat seine Grenze bereits die richtige Form für einen Service, und seine Beziehungen auf der Context Map sagen Ihnen, wie die Integration aussehen muss. Deshalb empfehlen viele Fachleute, zuerst die Kontexte zu finden und erst danach über das Deployment zu entscheiden. Auch das Umgekehrte gilt: Services, die quer zu Bounded Contexts geschnitten sind (ein „Order-Service“, in den jeder Kontext schreibt), ergeben den eng gekoppelten verteilten Monolithen, der in Abschnitt 6.3 behandelt wird. Beachten Sie auch, dass ein Bounded Context nicht automatisch ein Microservice ist; ein Kontext kann als mehrere Services deployt werden, und mehrere kleine Kontexte können sich ein Deployment teilen.