What needs to be finished first
A rough event timeline and pivotal events are documented so candidates for bounded contexts and their boundaries are available.
An overview of the existing contexts and their relationships (Customer-Supplier, Conformist, ACL) is available or being developed in parallel.
What needs to be ready before start
Bounded Context Canvas template (ddd-crew GitHub) as a Miro template or A1 printout; sticky notes in four colors for Domain Roles, Strategic Classification, Inbound, and Outbound; markers; glossary area at the edge.
One context owner (team lead or tech lead); two to three domain experts from the business domain; one to three engineers; optionally a DDD coach for the team's first canvases.
Provisional context name; list of known upstream and downstream systems with integration type; existing service documentation; relevant ADRs for interfaces.
1-3 h
Place the canvas on the work surface and label the fields (Name, Purpose, Strategic Classification, Domain Roles, Inbound Communication, Outbound Communication, Ubiquitous Language, Business Decisions, Assumptions). Put the glossary column on the right. Set the timer to 90 min.
The one question this method answers
Which domain boundary defines this context, which language applies inside it, and how does it integrate with its neighbors?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Name and purpose | 10 min | Use the context name as a domain term, not as a service name. Write the purpose in two sentences: which business problem this context solves and which outcome it produces. | If the name sounds like a microservice ('order-service'), it is too technical. Use a domain term from the ubiquitous language. |
2Section 2: Strategic classification | 10 min | Classify along three axes: Domain (Core, Supporting, Generic), Business Model (Revenue, Engagement, Compliance, Cost Reduction), Evolution (Genesis, Custom, Product, Commodity). | Core domains need the best people. If everything is classified as Core, the strategy is unclear or the team is overconfident. |
3Section 3: Domain roles | 10 min | Which role does the context play (Specification, Execution, Audit, Approver, Analysis, Gateway)? Multiple roles are possible, but they need justification. | More than three domain roles point to a God Context. Check whether the canvas should be split. |
4Section 4: Inbound and outbound communication | 30 min | For each interface: counterpart context, frequency, data, integration pattern (Customer-Supplier, Conformist, ACL, Open Host Service, Published Language). Separate inbound commands and queries from outbound events. | If inbound and outbound use different language, translation (ACL) is mandatory. Missing ACLs with differing language create model leaks. |
5Section 5: Ubiquitous language and business decisions | 20 min | Collect 10-20 central terms with a short definition. Note three to five important business decisions (rules, policies, invariants) enforced by the context. | If a term means different things to different stakeholders, define it here explicitly. Otherwise the ambiguity leaks into code and tickets. |
6Section 6: Assumptions and risks | 10 min | Capture open assumptions, missing clarity, and known risks. Name an owner and next action for each entry. | An empty assumptions block is a warning sign. Every context has uncertain assumptions; without this reflection, the canvas is polished but shallow. |
What comes out at the end
Completed canvas (image or structured Markdown) in the repo under `docs/contexts/<context-name>.md`, linked to the Context Map, relevant ADRs, and service documentation. Include version number and date in the header.
Keep every canvas in Git with version number in the filename or header. For larger changes (domain classification, new integrations), create a new version and keep the old one. Add a change log at the end with date and reason.
Compact working template for Bounded Context Canvas with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Purpose: Calculates final prices per order item while considering promotion rules, taxes, and volume discounts. Delivers traceable price breakdowns for audit and customer service.
Strategic Classification: Core / Revenue / Custom (the promotion engine is a differentiator).
Domain Roles: Execution, Specification.
Inbound:
promotion.activated, ~50/day)Outbound:
Ubiquitous Language (excerpt): Price (final, currency-coded), ListPrice, NetPrice, Promotion, Eligibility, PromotionStack, RoundingRule.
Business Decisions: Promotion stacking order is fixed (BOGO before percentage discount). VAT is always calculated last. Rounding to cents follows DIN 1333.
Assumptions: TaxService stays reachable synchronously (owner: @ben, spike on outage behavior by 25.05.). Promotion engine scales to 200/day (unclear on Cyber Monday).
Recognize symptoms and steer against them
Name and content describe a service, not a domain boundary. The language is technical (endpoints, queues).
Reset the canvas with a domain term. A domain expert must understand the name without backend knowledge.
Strategic classification is Core/Revenue everywhere, with no Generic or Supporting contexts.
Do a reality check with stakeholders: what would be buy instead of build? Where does the company really invest? More than 30% Core is usually overestimated.
Inbound language from upstream differs but is adopted directly.
Plan an ACL explicitly as an outbound component. Translate models into your own terms. Otherwise upstream refactoring directly impacts the context.
The ubiquitous language contains generic terms (Item, User, Order) without domain definition.
Write one sentence per term that captures the domain-specific meaning. What does 'Order' mean HERE, compared with 'Order' in the fulfillment context?
No open points are listed in the assumptions field and everything looks settled.
The facilitator asks: what do we not know? Which assumption could be wrong? Require at least three entries, otherwise the canvas is polished up.
The canvas is created once and then forgotten. Reality (code, interfaces) drifts away.
Set a quarterly review cadence or review after major changes. Keep the canvas in the repo next to code, not in the wiki. Drift then becomes visible in code review.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.