Domain Modeling Canvas

Bounded Context Canvas

Klärt Sprache, Modellgrenzen und Zuständigkeiten eines fachlichen Kontextes, bevor Integration und Teamgrenzen festgelegt werden.

Das Bounded Context Canvas gibt einem noch unscharfen fachlichen Kontext Form. Es klärt Sprache, Zuständigkeit, Integrationsraum und die Tragfähigkeit einer Grenze.

Kernfrage

Wo verläuft die Domänengrenze und wie arbeiten die Kontexte zusammen?

Bounded Context Canvas planen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 3-8
Zeit: 1-3 h

Die Schritte bilden einen möglichen Arbeitsweg. Passe sie an Zweck und verfügbare Belege der Methode an.

Papierillustration zu Bounded Context Canvas mit den zentralen Arbeitsschritten und einem sichtbaren Ergebnis.

Name
Kontext und Verantwortung benennen
Gib dem Bounded Context einen fachlichen Namen und formuliere, welche Verantwortung sein Modell erfüllt.
Sprache
Sprache und Modell festhalten
Definiere Schlüsselbegriffe kontextlokal mit Beispiel und Regel; notiere Synonyme oder Mehrdeutigkeit sichtbar.
Schnittstelle
Eingänge und Ausgänge klären
Liste fachliche Inputs und Outputs mit Produzent, Konsument, Vertrag und Änderungsrhythmus.
Grenze
Beziehungen und offene Grenzen prüfen
Prüfe Nachbarkontexte, Upstream/Downstream-Einflüsse und Übersetzungsbedarf; schreibe offene Grenzfragen mit Owner auf.

Überarbeite das Ergebnis, wenn sich Belege, Kontext oder Wirkung ändern. Halte fest, was sich geändert hat und warum.

Geeignet, wenn

Geeignet für: „DDD Context Design“, „Microservice Boundaries“. Beteiligte können die nötigen Belege und Entscheidungen einbringen.

Ideal für

DDD Context Design
Microservice Boundaries
Team Alignment

Nicht gut für

Sehr kleine Domänen
Reine UI-Flows

Ergebnisse

Bounded Context Canvas
Fachliche Verantwortung, lokale Sprache, Modell und Schnittstellen eines Kontextes.
Kontextcanvas mit geklärten und offenen Punkten
Das Artefakt hält Umfang, Datum, Beteiligte, Quellenstand und Verantwortung fest und dokumentiert geänderte Annahmen mit Änderungsgrund.

Bounded Context Canvas

Fiktives Beispiel

Fiktiv, Kontext „Terminplanung“: Verantwortung: buchbare Zeiten anbieten und bestätigen. Sprache: Slot = von der Praxis freigegebener Zeitraum; Termin = verbindliche Buchung. Eingang: Patient:innen- und Praxis-ID, gewünschter Zeitraum. Ausgang: bestätigte Buchung oder Ablehnung. Nachbarschaft: Praxisverwaltung liefert Verfügbarkeiten; Benachrichtigung erhält bestätigte Termine. Offene Grenze: Wer ist führend für Stornierungsstatus?

Name

Name den fachlichen Kontext.

Fiktiv: Terminplanung

Purpose

Welchen geschäftlichen Zweck erfüllt der Kontext?

Fiktiv: Buchbare Zeiten anbieten und bestätigen.

Strategische Klassifikation

Core, Supporting oder Generic; Wertbeitrag und Evolution begründen.

Fiktiv: Supporting; Product-Evolution ist Hypothese.

Domain Roles

Welche fachliche Rolle erfüllt der Kontext?

Fiktiv: Execution Context für Reservierungen.

Inbound Communication

Welche Messages und Collaborators senden hinein?

Fiktiv: Praxisverwaltung sendet verfügbare Slots.

Outbound Communication

Welche Commands, Events oder Queries gehen hinaus?

Fiktiv: AppointmentConfirmed an Benachrichtigung.

Ubiquitous Language

Welche lokalen Begriffe und Definitionen gelten?

Fiktiv: Slot = von Praxis freigegebener Zeitraum.

Business Decisions

Welche fachlichen Regeln oder Policies gelten?

Fiktiv: Doppelbuchung wird abgelehnt.

Assumptions

Welche Modellannahmen sind ungeprüft?

Fiktiv: Synchronisierung erneuert Slots vor Buchung.

Verification Metrics

Welche Signale prüfen, ob die Kontextgrenze passt?

Fiktiv: Konfliktrate und manuelle Eingriffe beobachten.

Open Questions

Was bleibt offen und wer untersucht es?

Fiktiv: Wer ist führend für Stornierungsstatus?

Bounded Context Canvas · DDD Crew

Erster Schritt

Gib dem Bounded Context einen fachlichen Namen und formuliere, welche Verantwortung sein Modell erfüllt.

Zur Methodenanleitung

Davor sinnvoll

Domain Modeling

EventStorming

Liefert Hot Spots und Sprachgrenzen, die der Canvas in ein Kontextmodell übersetzt.

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.

Architecture

Architecture Decision Record

Hält die geklärte Kontextgrenze als begründete Architekturentscheidung fest.

Knowledge Modeling

Event Modeling

Nutzt die geklärte Sprache und Zuständigkeit für ein Ablaufmodell des Kontexts.

Vertiefung

Zweck

Wenn ein fachlicher Kontext noch unscharf umrissen ist, bringt sie Sprache, Zuständigkeit und Integrationsraum in Form. Sie klärt, was zusammengehört und wo eine Grenze tragfähig sein muss.

Funktionsweise

Sie verdichtet Kontext, Begriffe, Ein- und Ausgänge sowie Ownership in einer kompakten Sicht. So werden Schnittstellen, Risiken und Abhängigkeiten schnell sichtbar, ohne die Domäne unnötig aufzublähen.

Im Detail

Die Canvas arbeitet stark, weil sie Sprache, Verantwortung und Schnittstellen in einen gemeinsamen Ausschnitt zwingt und damit diffuse Architekturgespräche fachlich erdet. Wirksam wird sie erst, wenn jedes Feld eine belastbare Aussage über Ownership, Ein und Ausgänge oder Modellgrenzen trägt. Mechanisch ausgefüllt produziert sie Vollständigkeitsschein, sorgfältig genutzt legt sie Konflikte frei, bevor Teams oder Integrationen daran scheitern.

Durchführung

Lege vorab konkrete Domänenbeispiele, zentrale Begriffe und bekannte Übergaben zwischen Teams bereit, damit die Felder nicht abstrakt bleiben. Der wichtige Moment kommt, wenn unklar wird, ob etwas innen oder außen liegt. Schließe mit wenigen Grenzentscheidungen, offenen Schnittstellenfragen und einem nächsten Prüfschritt am realen System.

Die Methodenanleitung führt mit 4 Phasen, Zeitrahmen, 4 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Domain-Driven Design Grenzen Modellierung

Quellen

Bounded Context Canvas · DDD Crewgithub.comDDD-Crew-Repository auf GitHub; kanonische Vorlage und Anleitung zum Bounded Context Canvas mit Beispielen und Formaten.

In Playbooks

Domain Discovery zu Systemgrenzen führenVon fachlichem Ablauf zu Sprache, Events, Bounded Contexts und ersten Architekturgrenzen.

Artefakt-Vorlagen

Bounded Context Canvas: ArbeitsvorlageBereite Entscheidung, Quellenbelege und nächste Prüfung vor.

canvas

bounded-context-canvas-working-template.md

Bereite Entscheidung, Quellenbelege und nächste Prüfung vor.

Bounded Context Canvas: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Methode durchführen Zeit: Siehe Zeitrahmen im Katalog; keine allgemeine Dauer.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Gemeinsame Arbeitsfläche, Quellenbelege und eine abgestimmte Entscheidungsfrage.
Rollen: Fachexpertise, Product Owner, Architektur, Vertretungen benachbarter Kontexte.
Vorab-Infos: Sammle vorhandene Daten, Beispiele, Rahmenbedingungen und relevante Perspektiven.
Gesamter Zeitbedarf: 90–150 Min. je Kontextkandidat; Grenzen mit Nachbarteams prüfen.
Setup: Sie verdichtet Kontext, Begriffe, Ein- und Ausgänge sowie Ownership in einer kompakten Sicht. So werden Schnittstellen, Risiken und Abhängigkeiten schnell sichtbar, ohne die Domäne unnötig aufzublähen.