Stimmt Gegenstand, Grenze und Entscheidung ab, bevor ihr das Modell füllt.
Bounded Context Canvas
Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.
Vorbedingung
Was vorher fertig sein muss
Bringt Quellen und Personen mit Prozesswissen ein; trennt Fakten von Annahmen.
Vorbereitung
Was vor Start vorliegen muss
Gemeinsame Arbeitsfläche, Quellenbelege und eine abgestimmte Entscheidungsfrage.
Fachexpertise, Product Owner, Architektur, Vertretungen benachbarter Kontexte.
Sammle vorhandene Daten, Beispiele, Rahmenbedingungen und relevante Perspektiven.
90–150 Min. je Kontextkandidat; Grenzen mit Nachbarteams prüfen.
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.
Kernfrage
Die eine Frage, die diese Methode beantwortet
Wo verläuft die Domänengrenze und wie arbeiten die Kontexte zusammen?
Ablauf
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
Das Bounded Context Canvas gibt einem noch unscharfen fachlichen Kontext Form. Es klärt Sprache, Zuständigkeit, Integrationsraum und die Tragfähigkeit einer Grenze.
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?
- 1
Name
Kontext und Verantwortung benennen

Ziel
Kontextname und Zweck
Voraussetzungen für diesen Schritt
- Fachliche Fähigkeit, Team- und Entscheidungsmandat
Durchführung
- Gib dem Bounded Context einen fachlichen Namen und formuliere, welche Verantwortung sein Modell erfüllt.
Ergebnis
Kontextname und Zweck
Kontextname und Zweck
Qualitätscheck
Ist die Grenze durch eine fachliche Verantwortung begründet?
Stolperfalle
Die Grenze folgt allein der vorhandenen Code- oder Teamstruktur. Untersuche Sprache, Regeln und Änderungsgründe vor der Zuordnung.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
- 2
Sprache
Sprache und Modell festhalten

Ziel
Ubiquitous Language und Kernmodell
Voraussetzungen für diesen Schritt
- Fachleute, Beispiele und strittige Begriffe
Durchführung
- Definiere Schlüsselbegriffe kontextlokal mit Beispiel und Regel; notiere Synonyme oder Mehrdeutigkeit sichtbar.
Ergebnis
Ubiquitous Language und Kernmodell
Ubiquitous Language und Kernmodell
Qualitätscheck
Verstehen Fachleute jeden Begriff gleich?
Stolperfalle
Gleiche Wörter werden über Kontexte hinweg als gleiches Modell angenommen. Dokumentiere kontextbezogene Definitionen und Übersetzungen.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
- 3
Schnittstelle
Eingänge und Ausgänge klären

Ziel
Schnittstellenübersicht
Voraussetzungen für diesen Schritt
- Nachbarsysteme, Events, APIs und Datenverantwortung
Durchführung
- Liste fachliche Inputs und Outputs mit Produzent, Konsument, Vertrag und Änderungsrhythmus.
Ergebnis
Schnittstellenübersicht
Schnittstellenübersicht
Qualitätscheck
Ist für jedes Datum eine führende Quelle genannt?
Stolperfalle
Datenflüsse erscheinen ohne Owner oder Vertrag. Ergänze Quelle, Empfänger und Fehlerverantwortung.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
- 4
Grenze
Beziehungen und offene Grenzen prüfen

Ziel
Kontextcanvas mit geklärten und offenen Punkten
Voraussetzungen für diesen Schritt
- Kontextmodell, Teamzuständigkeiten, Integrationsfälle
Durchführung
- Prüfe Nachbarkontexte, Upstream/Downstream-Einflüsse und Übersetzungsbedarf; schreibe offene Grenzfragen mit Owner auf.
Ergebnis
Kontextcanvas mit geklärten und offenen Punkten
Kontextcanvas mit geklärten und offenen Punkten
Qualitätscheck
Sind Abhängigkeiten und Übersetzung explizit?
Stolperfalle
Canvas wird vorschnell als verbindliche Teamtopologie behandelt. Trenne Modellgrenze von Teamentscheidung und validiere beide separat.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
Artefakt
Was am Ende rauskommt
Skizze: so sieht das Artefakt aus
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.
Notiere Umfang, Datum, Beteiligte, Quellenstand und Verantwortung. Halte geänderte Annahmen samt Änderungsgrund fest.
- Gemeinsames Whiteboard oder Papiervorlage
- Quellen, Aufzeichnungen oder Messdaten
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.
Für die Arbeitsschritte bereitstellen
Name: Kontext und Verantwortung benennen
- Fachliche Fähigkeit, Team- und Entscheidungsmandat
Sprache: Sprache und Modell festhalten
- Fachleute, Beispiele und strittige Begriffe
Schnittstelle: Eingänge und Ausgänge klären
- Nachbarsysteme, Events, APIs und Datenverantwortung
Grenze: Beziehungen und offene Grenzen prüfen
- Kontextmodell, Teamzuständigkeiten, Integrationsfälle
Bounded Context Canvas
Name
Name den fachlichen Kontext.
...
Purpose
Welchen geschäftlichen Zweck erfüllt der Kontext?
...
Strategische Klassifikation
Core, Supporting oder Generic; Wertbeitrag und Evolution begründen.
...
Domain Roles
Welche fachliche Rolle erfüllt der Kontext?
...
Inbound Communication
Welche Messages und Collaborators senden hinein?
...
Outbound Communication
Welche Commands, Events oder Queries gehen hinaus?
...
Ubiquitous Language
Welche lokalen Begriffe und Definitionen gelten?
...
Business Decisions
Welche fachlichen Regeln oder Policies gelten?
...
Assumptions
Welche Modellannahmen sind ungeprüft?
...
Verification Metrics
Welche Signale prüfen, ob die Kontextgrenze passt?
...
Open Questions
Was bleibt offen und wer untersucht es?
...
Bounded Context Canvas · DDD Crew
Name: Kontext und Verantwortung benennen
Erwartetes Artefakt: Kontextname und Zweck
Kontextname und Zweck
Eintrag:
...
- Ist die Grenze durch eine fachliche Verantwortung begründet?
Sprache: Sprache und Modell festhalten
Erwartetes Artefakt: Ubiquitous Language und Kernmodell
Ubiquitous Language und Kernmodell
Eintrag:
...
- Verstehen Fachleute jeden Begriff gleich?
Schnittstelle: Eingänge und Ausgänge klären
Erwartetes Artefakt: Schnittstellenübersicht
Schnittstellenübersicht
Eintrag:
...
- Ist für jedes Datum eine führende Quelle genannt?
Grenze: Beziehungen und offene Grenzen prüfen
Erwartetes Artefakt: Kontextcanvas mit geklärten und offenen Punkten
Kontextcanvas mit geklärten und offenen Punkten
Eintrag:
...
- Sind Abhängigkeiten und Übersetzung explizit?
Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/bounded-context-canvas/run-sheet
Beispielausgabe
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
bounded-context-canvas-beispiel.md
Konkret gefülltes Szenario, 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?
Stolperfallen
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
- Kontext und Verantwortung benennenDie Grenze folgt allein der vorhandenen Code- oder Teamstruktur.In der Phase ansehen
- Sprache und Modell festhaltenGleiche Wörter werden über Kontexte hinweg als gleiches Modell angenommen.In der Phase ansehen
- Eingänge und Ausgänge klärenDatenflüsse erscheinen ohne Owner oder Vertrag.In der Phase ansehen
- Beziehungen und offene Grenzen prüfenCanvas wird vorschnell als verbindliche Teamtopologie behandelt.In der Phase ansehen
Kontext und Verantwortung benennen
Die Grenze folgt allein der vorhandenen Code- oder Teamstruktur.
Untersuche Sprache, Regeln und Änderungsgründe vor der Zuordnung.
Sprache und Modell festhalten
Gleiche Wörter werden über Kontexte hinweg als gleiches Modell angenommen.
Dokumentiere kontextbezogene Definitionen und Übersetzungen.
Eingänge und Ausgänge klären
Datenflüsse erscheinen ohne Owner oder Vertrag.
Ergänze Quelle, Empfänger und Fehlerverantwortung.
Beziehungen und offene Grenzen prüfen
Canvas wird vorschnell als verbindliche Teamtopologie behandelt.
Trenne Modellgrenze von Teamentscheidung und validiere beide separat.
Abbruchkriterien
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Methodenanleitung durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.

