Vom Klebezettel zum Bounded Context: wie aus einem Workshop Architektur wird

Teil 4 der Reihe "Software gemeinsam gestalten". Zur Übersicht

Nach einem Event Storming hängen Hunderte Klebezettel an der Wand. Der Ablauf ist sichtbar, die Fachsprache liegt auf dem Tisch, und das Team hat ein gemeinsames Bild. Die nächste Frage lautet: Wo ziehen wir die Grenzen, die aus diesem Bild eine tragfähige Software-Architektur machen?

Was ein Bounded Context ist

Ein Bounded Context ist ein klar abgegrenzter Bereich, in dem ein bestimmtes Fachmodell gilt. Innerhalb dieser Grenze haben Begriffe eine eindeutige Bedeutung, und das Modell ist in sich konsistent. Der Begriff stammt aus dem Domain-Driven Design und löst ein praktisches Problem: Große Domänen lassen sich als ein einziges Modell weder verstehen noch warten.

Ein Beispiel: Das Wort "Kontakt" bedeutet im Fundraising eine Spender:in mit Kommunikationshistorie und im Rechnungswesen eine Adresse mit Steuernummer. Beide Abteilungen meinen etwas Verschiedenes, und beide haben recht. Ein gemeinsames Modell, das beides abdecken soll, wird für keine Seite handlich. Zwei getrennte Kontexte mit einer klaren Schnittstelle dazwischen passen besser zur Realität.

Von der Wand zur Grenze

Die Klebezettel aus dem Event Storming liefern die Hinweise, aus denen sich Kontextgrenzen ableiten lassen. Vier Signale sind besonders aufschlussreich:

1. 01

   Sprachwechsel

   Sobald das Team beginnt, dieselben Begriffe anders zu verwenden oder neue einzuführen, deutet das auf eine Kontextgrenze hin. Die Klebezettel machen das sichtbar, weil die Beschriftungen von verschiedenen Personen stammen.

2. 02

   Verantwortungswechsel

   Wenn sich die Zuständigkeit ändert, etwa vom Fundraising zur Buchhaltung, ist das ein starkes Signal. Jedes Team verantwortet seinen Teil des Ablaufs und braucht ein eigenes Modell dafür.

3. 03

   Zeitliche Entkopplung

   Ereignisse, die Minuten, Stunden oder Tage auseinanderliegen, gehören oft zu verschiedenen Kontexten. Eine Spende entgegennehmen und eine Zuwendungsbestätigung verschicken folgen eigenen Regeln und Rhythmen.

4. 04

   Entscheidungslogik

   Wo sich Geschäftsregeln grundlegend ändern, etwa von "Spende verbuchen" zu "Kampagne planen", arbeitet ein anderes Modell. Unterschiedliche Regeln deuten auf unterschiedliche Kontexte.

Der Schnitt in der Praxis

Wir gehen die Wand gemeinsam mit dem Team durch und gruppieren Ereignisse, die fachlich zusammengehören. Dann benennen wir die Gruppen, am besten mit dem Begriff, den das Team selbst verwendet. Diese Gruppen sind die Kandidaten für Bounded Contexts. Zwischen ihnen identifizieren wir die Schnittstellen: Welche Informationen fließen von einem Kontext in den anderen, und in welcher Form?

Die Kontextgrenzen bestimmen, wie die Software in Bausteine und Zuständigkeitsbereiche geschnitten wird. Sie bestimmen auch, welches Team für welchen Teil zuständig ist. Ein guter Schnitt orientiert sich an der Fachlichkeit, und damit an den Grenzen, die das Team selbst benennen kann.

Typische Stolperstellen

• Zu wenige Kontexte: Ein einziges Modell für alles wird unübersichtlich und schwer änderbar. Im Zweifel lieber feiner schneiden.
• Entlang der Technik schneiden: Wenn die Bereiche "Datenbank", "Automatisierung" oder "Benutzeroberfläche" heißen, folgt der Schnitt der Technik. Die Architektur sollte eure Fachlichkeit abbilden, etwa Fundraising, Projektsteuerung oder Kommunikation.
• Schnittstellen vergessen: Kontexte brauchen klare Absprachen, wie sie Informationen austauschen. Diese Absprachen gehören genauso zum Entwurf wie die Kontexte selbst.

Die richtigen Grenzen zu finden, ist eine fachliche Entscheidung.

Vom Schnitt zur gemeinsamen Sprache

Innerhalb jedes Bounded Context gilt eine eigene, präzise Fachsprache, die Ubiquitous Language. Sie sorgt dafür, dass Code und Gespräch deckungsgleich bleiben. Im nächsten und letzten Teil der Reihe zeigen wir, wie ihr diese Sprache aufbaut und lebendig haltet.