Einführung in Bounded Contexts
In der Folge vom 14. April 2025 des "DDD Live"-Streams befasste sich Matthias Bohlen mit dem Thema "Bounded Context" im Domain-Driven Design (DDD). Als erfahrener Trainer für DDD erklärt er, dass Bounded Contexts ein exzellentes Mittel sind, um Aufwand bei der Softwareentwicklung zu reduzieren. Der Stream baut auf einer früheren Session auf, in der die Grundlagen von DDD und ein Beispiel-Domäne - betriebliche Verbesserungsvorschläge - vorgestellt wurden.
Matthias erläutert zunächst das zentrale Problem: In umfangreichen Domänen entstehen häufig Mehrdeutigkeiten im Modell. Der Begriff "Vorschlag" kann für einen Mitarbeiter etwas anderes bedeuten als für das Management. Diese unterschiedlichen Verständnisse führen zu Kommunikationsproblemen, die durch Bounded Contexts gelöst werden können.
Die frühen Jahre: Warum große Modelle scheiterten
Um die Bedeutung von Bounded Contexts zu verdeutlichen, greift Matthias auf historische Beispiele zurück. In den 1980er Jahren versuchten viele Unternehmen, ein großes und einheitliches Modell für ihre gesamte Firma zu erstellen. Besonders Versicherungen waren hier Vorreiter.
Anhand des Versicherungswesens erklärt er, wie ein und derselbe Begriff (z.B. "Police" oder "Leistung") aus unterschiedlichen Perspektiven völlig unterschiedliche Bedeutungen haben kann:
- Für den Vertrieb ist eine Police ein Verkaufsprodukt
- Für das Risikomanagement repräsentiert sie ein Risiko
- Für den Kunden bedeutet sie Sicherheit
Diese verschiedenen Sichtweisen führten zu riesigen Datenbanktabellen mit vielen Spalten und endlosen Diskussionen über die "richtige" Definition der Begriffe.
Warum Kontext entscheidend ist
Matthias erläutert die linguistische Herkunft des Begriffs "Kontext": Das Wort selbst (Text) erhält seine Bedeutung erst durch den Kontext (den umgebenden Text). Er zeigt am Beispiel des Wortes "Leistung", wie unterschiedlich es interpretiert werden kann:
- Im Versicherungskontext: eine Auszahlung
- Im Sportkontext: eine Anstrengung oder ein erreichtes Ziel
- In der Physik: Arbeit pro Zeiteinheit
Die Lösung im Domain Driven Design besteht darin, sich zunächst über die Kontexte klar zu werden und dann kleinere Modelle innerhalb dieser Kontexte zu definieren. Ein Bounded Context ist eine Beschreibung einer Grenze, innerhalb derer ein Modell sauber definiert und anwendbar ist.
Praktische Anwendung: Bounded Contexts identifizieren
Anhand des Event Storming Boards aus der vorherigen Session demonstriert Matthias, wie man Bounded Contexts identifiziert. Für das Beispiel des betrieblichen Vorschlagswesens identifiziert er vier Bounded Contexts:
- Vorschlag: Alles rund um die Ideenfindung bis zur Formulierung eines Vorschlags
- Budget: Der finanzielle Aspekt, Kostenermittlung und Budgetierung
- Plan: Die zeitliche Planung, Prüfung der Arbeitskraft, Teams einladen
- Projekt: Die tatsächliche Umsetzung des Vorschlags
Er erstellt eine Kontextmap, die diese Bereiche und ihre Beziehungen visualisiert. Diese Aufteilung der Domäne in Bereiche mit gemeinsamem Verständnis bezeichnet er als "strategisches Design".
Beziehungen zwischen Bounded Contexts
Matthias erklärt, dass Bounded Contexts miteinander kommunizieren müssen. Er zeigt, wie man diese Schnittstellen identifiziert:
- Zwischen Vorschlags- und Planungskontext
- Zwischen Budget und Planung
- Zwischen Planung und Projekt
Bei diesen Schnittstellen spielt das Konzept von "Upstream" und "Downstream" eine wichtige Rolle. Ein "Upstream"-Kontext gibt die Sprache vor, an die sich ein "Downstream"-Kontext anpassen muss. Diese Beziehungen werden von verschiedenen Faktoren beeinflusst, wie z.B.:
- Welcher Kontext war zuerst da?
- Handelt es sich um ein eingekauftes oder selbstentwickeltes System?
- Ist das System spezifisch oder generisch?
Ausblick und nächste Schritte
Zum Abschluss gibt Matthias einen Ausblick auf den nächsten Stream. Dort wird er sich mit der Prozessmodellierung innerhalb der identifizierten Bounded Contexts befassen. Er wird zeigen, wie die Teams konkrete Prozesse modellieren können, beispielsweise den Prozess der Vorschlagserarbeitung: Wie kommt man von einer Idee zu einem ausformulierten Vorschlag?
Die Kontextmap gibt bereits einen ersten Anhaltspunkt dafür, wie viele Teams benötigt werden und welche Schnittstellen zwischen ihnen bestehen müssen. Die nächsten Schritte werden dann die konkreten Prozesse innerhalb dieser Kontexte beleuchten.
Viel Spaß beim Zuschauen, seien Sie beim nächsten Mal auch LIVE dabei und kommentieren Sie im Chat!
