Was vorher fertig sein muss
Eine grobe Event-Timeline und Pivotal Events sind dokumentiert, sodass Kandidaten für Bounded Contexts und ihre Grenzen vorliegen.
Eine Übersicht der bestehenden Contexts und ihrer Beziehungen (Customer-Supplier, Conformist, ACL) liegt vor oder wird parallel erarbeitet.
Was vor Start vorliegen muss
Bounded-Context-Canvas-Template (ddd-crew GitHub) als Miro-Vorlage oder A1-Druck; Stickies in vier Farben für Domain Roles, Strategic Classification, Inbound, Outbound; Marker; Glossar-Bereich am Rand.
Ein Context-Owner (Team Lead oder Tech Lead); zwei bis drei Domain-Experten aus dem Fachbereich; ein bis drei Engineers; optional ein DDD-Coach für die ersten Canvases im Team.
Vorläufiger Context-Name; Liste bekannter Up- und Downstream-Systeme mit Integrationsart; bestehende Service-Dokumentation; relevante ADRs zu Schnittstellen.
1-3 h
Canvas auf Arbeitsfläche legen, Felder beschriften (Name, Purpose, Strategic Classification, Domain Roles, Inbound Communication, Outbound Communication, Ubiquitous Language, Business Decisions, Assumptions). Glossar-Spalte rechts. Timer auf 90 min.
Die eine Frage, die diese Methode beantwortet
Welche fachliche Grenze definiert diesen Context, welche Sprache gilt darin und wie integriert er sich mit Nachbarn?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Name und Purpose | 10 min | Context-Name als fachlicher Begriff, nicht als Service-Name. Purpose in zwei Sätzen: welches Geschäftsproblem dieser Context löst und welches Outcome er erzeugt. | Wenn der Name wie ein Microservice klingt („order-service“), ist er zu technisch. Fachlicher Begriff aus der Ubiquitous Language nutzen. |
2Sektion 2: Strategic Classification | 10 min | Drei Achsen einordnen: Domain (Core, Supporting, Generic), Business Model (Revenue, Engagement, Compliance, Cost Reduction), Evolution (Genesis, Custom, Product, Commodity). | Core-Domains brauchen die besten Leute. Wenn alles als Core klassifiziert wird, ist die Strategie unklar oder das Team überschätzt sich. |
3Sektion 3: Domain Roles | 10 min | Welche Rolle spielt der Context (Specification, Execution, Audit, Approver, Analysis, Gateway)? Mehrere Rollen möglich, aber begründet. | Mehr als drei Domain Roles deuten auf einen God-Context hin. Aufteilung in mehrere Canvases prüfen. |
4Sektion 4: Inbound und Outbound Communication | 30 min | Pro Schnittstelle: Counterpart-Context, Frequenz, Daten, Integrationsmuster (Customer-Supplier, Conformist, ACL, Open Host Service, Published Language). Inbound Commands und Queries getrennt von Outbound Events. | Wenn die Sprache zwischen Inbound und Outbound differiert, ist Übersetzung (ACL) zwingend. Fehlende ACL bei abweichender Sprache erzeugt Modell-Leck. |
5Sektion 5: Ubiquitous Language und Business Decisions | 20 min | 10-20 zentrale Begriffe sammeln, mit kurzer Definition. Drei bis fünf wichtige Business Decisions notieren (Regeln, Policies, Invariants), die der Context durchsetzt. | Wenn ein Begriff in unterschiedlichen Stakeholder-Köpfen unterschiedlich besetzt ist, gehört er hier explizit definiert. Sonst leakt die Mehrdeutigkeit in Code und Tickets. |
6Sektion 6: Assumptions und Risiken | 10 min | Offene Annahmen, fehlende Klarheit und bekannte Risiken festhalten. Pro Eintrag Owner und nächste Aktion benennen. | Leerer Assumptions-Block ist ein Warnzeichen. Jeder Context hat unsichere Annahmen, fehlt diese Reflexion, ist der Canvas geschönt. |
Was am Ende rauskommt
Ausgefülltes Canvas (Bild oder strukturiertes Markdown) im Repo unter `docs/contexts/<context-name>.md`, verlinkt zu Context Map, relevanten ADRs und Service-Dokumentation. Versionsnummer und Datum im Header.
Jeder Canvas im Git mit Versionsnummer im Dateinamen oder Header. Bei größeren Änderungen (Domain-Klassifikation, neue Integrationen) neue Version, alte behalten. Änderungs-Log am Ende mit Datum und Anlass.
Kompakte Arbeitsvorlage für Bounded Context Canvas mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Bounded Context Canvas Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Context Canvas:
- Glossary:
- Integration Notes:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## Bounded Context Canvas — Pricing (v2, 2026-05-18)
**Purpose**: Berechnet finale Preise pro Order-Item unter Berücksichtigung von Promotion-Regeln, Steuern und Mengenrabatten. Liefert nachvollziehbare Preisaufschlüsselungen für Audit und Customer Service.
**Strategic Classification**: Core / Revenue / Custom (Promotion-Engine ist Differenzierungsfaktor).
**Domain Roles**: Execution, Specification.
**Inbound**:
- Ordering (Customer-Supplier, Command CalculatePrice, ~80k/Tag)
- Catalog (Conformist via REST, Query GetProduct, ~80k/Tag)
- Promotion (Published Language via Kafka topic `promotion.activated`, ~50/Tag)
**Outbound**:
- PriceCalculated Event (Published Language, an Ordering und Analytics)
- TaxRequested Command an TaxService (Customer-Supplier mit ACL)
**Ubiquitous Language (Auszug)**: Price (final, currency-coded), ListPrice, NetPrice, Promotion, Eligibility, PromotionStack, RoundingRule.
**Business Decisions**: Promotion-Stacking-Reihenfolge ist fix (BOGO vor Prozent-Rabatt). MwSt wird immer am Schluss berechnet. Rundung auf Cent nach DIN 1333.
**Assumptions**: TaxService bleibt synchron erreichbar (Owner: @ben, Spike Ausfall-Verhalten bis 25.05.). Promotion-Engine skaliert auf 200/Tag (unklar bei Cyber Monday).Symptome erkennen, gegensteuern
Name und Inhalt beschreiben einen Service, nicht eine fachliche Grenze. Sprache ist technisch (Endpoints, Queues).
Canvas neu aufsetzen mit fachlichem Begriff. Domain-Experte muss den Namen verstehen, ohne Backend-Wissen.
Strategic Classification ist überall Core/Revenue, keine Generic- oder Supporting-Contexts.
Reality-Check mit Stakeholdern: was wäre buy-statt-build? Wo investiert das Unternehmen wirklich? Mehr als 30% Core ist meist überschätzt.
Inbound-Sprache aus Upstream unterscheidet sich, wird aber direkt übernommen.
ACL explizit als Outbound-Komponente einplanen. Modelle übersetzen in eigene Begriffe. Sonst hat Upstream-Refactoring direkten Impact auf den Context.
Ubiquitous Language enthält generische Begriffe (Item, User, Order) ohne Domain-Definition.
Pro Begriff einen Satz, der die Domain-spezifische Bedeutung festhält. Was bedeutet „Order“ HIER, im Unterschied zu „Order“ in Fulfillment-Context?
Im Assumption-Feld stehen keine offenen Punkte, alles wirkt geklärt.
Facilitator fragt nach: was wissen wir nicht? Welche Annahme könnte falsch sein? Mindestens drei Einträge erzwingen, sonst ist das Canvas geschönt.
Canvas wird einmal erstellt, dann vergessen. Realität (Code, Schnittstellen) driftet ab.
Review-Cadence pro Quartal oder bei großen Änderungen. Canvas im Repo neben Code, nicht im Wiki. Drift wird im Code-Review sichtbar.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.