Complete firstDomain knowledge
Domain experts can explain terms and business rules through real workflows.
Without domain language the result can become a system-box diagram.
Method guideDomain Modeling
Domain Context Map
A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
ComplexityMedium
Time1-3 h
Participants3-10
FormatWorkshop
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstBoth sides
Representatives of involved teams can confirm dependencies and influence.
Mark unilateral assumptions as unresolved.
02
Preparation
What needs to be ready before start
Materials
Context cards, integration contracts, team list, arrows with a U/D legend and domain-term notes.
People / roles
Domain experts, model owners, involved development teams and facilitator.
Pre-read
Collect a domain slice, concrete business workflows, team ownership and known interfaces. Keep current and target views separate.
Time needed
90–180 minutes for an initial slice; further modelling sessions as needed
Setup
Lay out context cards with terms and owners; add a U/D legend and derive connections from concrete integrations.
03
Core question
The one question this method answers
Where do particular models apply and how must their owning teams collaborate?
04
Flow
Phases with goal, actions, output and pitfall
A context map shows bounded contexts with their own domain language and model ownership, plus integration and team relationships. Upstream and downstream describe model dependency, not automatically the direction of a data packet.
Domain Context Map· worksheet
Fictional example
A context map shows bounded contexts with their own domain language and model ownership, plus integration and team relationships. Upstream and downstream describe model dependency, not automatically the direction of a data packet.
Context inventory
Record purpose, domain terms, boundaries and owner per context.
Fictional: Catalog (Offering team) manages courses; Enrollment (Participation team) manages seat reservations; Billing (Finance team) manages receivables.
Relationship 1
Record contexts, U/D roles, contract, patterns and change coordination.
Catalog U → Enrollment D: course ID and offering via a versioned API. Catalog offers OHS/Published Language; Enrollment translates external statuses through an ACL into its reservation model.
Relationship 2
Describe another relationship including influence over the interface.
Enrollment U → Billing D: confirmed enrolment event. Customer/Supplier: Billing can negotiate required billing fields with the Participation team.
Open modelling question
Which meaning or responsibility is unclear, who will clarify it and with what evidence?
On cancellation, reservation status differs from receivable status. Both teams review three cancellation cases by Friday and document event rules.
All example details are fictional and illustrate the application.
- 1
Contexts
Bound contexts
Goal
Context inventory
Inputs for this step
- Business workflows
- Terms and rules
Actions
- Identify areas with a consistent model using terms and rules.
- Record responsibility, core terms and boundaries per context; do not equate subdomain or deployment with context.
Output
Context inventory
Does a consistent domain language apply within each boundary?
Quality check
Does a consistent domain language apply within each boundary?
Pitfall
Every microservice becomes a bounded context without examination. Compare model meanings and justify boundaries in domain terms.
Timing: 20–40 minutes
- 2
Ownership
Ownership and current state
Goal
Confirmed ownership
Inputs for this step
- Context inventory
- Team representatives
Actions
- Assign each context to an owning team and collect current integrations.
- Mark actual state and desired future in separate versions.
Output
Confirmed ownership
Are ownership and current-state status confirmed?
Quality check
Are ownership and current-state status confirmed?
Pitfall
Desired architecture hides current dependencies. First map contracts and responsibilities actually in use.
Timing: 15–25 minutes
- 3
Dependency
Label dependencies
Goal
Labelled context relationships
Inputs for this step
- Integrations
- Model dependencies
Actions
- Determine upstream/downstream model dependency or a symmetric relationship for each connected pair.
- Label domain exchange and contract boundary on the connection.
Output
Labelled context relationships
Is the arrow meaning explained in a legend?
Quality check
Is the arrow meaning explained in a legend?
Pitfall
Data flow is confused with influence direction. Label both perspectives separately and check with the teams.
Timing: 20–35 minutes
- 4
Patterns
Examine relationship patterns
Goal
Justified relationship patterns
Inputs for this step
- Context relationships
- Team agreements
Actions
- Choose and justify team and integration patterns, such as Customer/Supplier, Partnership, Conformist or Anti-Corruption Layer.
- Record Shared Kernel only with joint change governance; mark assumptions.
Output
Justified relationship patterns
Does the pattern describe actual collaboration and translation?
Quality check
Does the pattern describe actual collaboration and translation?
Pitfall
Patterns become decorative labels without agreement. Clarify consequences for changes, translation and coordination per pattern.
Timing: 20–40 minutes
- 5
Risks
Risks and next modelling
Goal
Reviewed map and clarification tasks
Inputs for this step
- Map draft
- Concrete business cases
Actions
- Review conflicting terms, unmaintained contracts and tight coupling with both sides.
- Agree a specific modelling or contract clarification task with owner and date.
Output
Reviewed map and clarification tasks
Does each unresolved relationship have a clarification task?
Quality check
Does each unresolved relationship have a clarification task?
Pitfall
The map immediately triggers a large redesign. First test the highest-risk assumption against a business case.
Timing: 15–30 minutes
05
Artifact
What comes out at the end
Sketch: what the artifact looks like
Form
Versioned context map with boundaries, domain terms, owners, directed dependencies, relationship patterns and open modelling questions.
Versioning / ownership
Record date and scope; retain the previous version and reason when changing it.
Tool alternatives
- Whiteboard with context cards
- Versioned diagram file
- Context Mapper or text document
domain-context-map-working-template.md
Collect a domain slice, concrete business workflows, team ownership and known interfaces. Keep current and target views separate.
Domain Context Map: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Complete cycle Time: 90–180 minutes for an initial slice; further modelling sessions as needed
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Context cards, integration contracts, team list, arrows with a U/D legend and domain-term notes.
- Roles: Domain experts, model owners, involved development teams and facilitator.
- Advance information: Collect a domain slice, concrete business workflows, team ownership and known interfaces. Keep current and target views separate.
- Overall time needed: 90–180 minutes for an initial slice; further modelling sessions as needed
- Setup: Lay out context cards with terms and owners; add a U/D legend and derive connections from concrete integrations.
Prepare for the work steps
Contexts: Bound contexts
- Business workflows
- Terms and rules
Ownership: Ownership and current state
- Context inventory
- Team representatives
Dependency: Label dependencies
- Integrations
- Model dependencies
Patterns: Examine relationship patterns
- Context relationships
- Team agreements
Risks: Risks and next modelling
- Map draft
- Concrete business cases
Domain Context Map· worksheet
Context inventory
Record purpose, domain terms, boundaries and owner per context.
...
Relationship 1
Record contexts, U/D roles, contract, patterns and change coordination.
...
Relationship 2
Describe another relationship including influence over the interface.
...
Open modelling question
Which meaning or responsibility is unclear, who will clarify it and with what evidence?
...
Answer the prompts with your own information. Explicitly mark unknowns and assumptions.
Contexts: Bound contexts
Expected artifact: Context inventory
Does a consistent domain language apply within each boundary?
Entry:
...
- Does a consistent domain language apply within each boundary?
Ownership: Ownership and current state
Expected artifact: Confirmed ownership
Are ownership and current-state status confirmed?
Entry:
...
- Are ownership and current-state status confirmed?
Dependency: Label dependencies
Expected artifact: Labelled context relationships
Is the arrow meaning explained in a legend?
Entry:
...
- Is the arrow meaning explained in a legend?
Patterns: Examine relationship patterns
Expected artifact: Justified relationship patterns
Does the pattern describe actual collaboration and translation?
Entry:
...
- Does the pattern describe actual collaboration and translation?
Risks: Risks and next modelling
Expected artifact: Reviewed map and clarification tasks
Does each unresolved relationship have a clarification task?
Entry:
...
- Does each unresolved relationship have a clarification task?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/domain-context-map/run-sheet
06
Example output
Concrete filled scenario, fictional example
Fictional example for orientation. Counts and timings describe this case and are not universal requirements.
domain-context-map-beispiel.md
Concrete filled scenario, fictional example
Fictional example
Context inventory: Fictional: Catalog (Offering team) manages courses; Enrollment (Participation team) manages seat reservations; Billing (Finance team) manages receivables.
Relationship 1: Catalog U → Enrollment D: course ID and offering via a versioned API. Catalog offers OHS/Published Language; Enrollment translates external statuses through an ACL into its reservation model.
Relationship 2: Enrollment U → Billing D: confirmed enrolment event. Customer/Supplier: Billing can negotiate required billing fields with the Participation team.
Open modelling question: On cancellation, reservation status differs from receivable status. Both teams review three cancellation cases by Friday and document event rules.
07
Pitfalls
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
- Bound contextsEvery microservice becomes a bounded context without examination.View in phase
- Ownership and current stateDesired architecture hides current dependencies.View in phase
- Label dependenciesData flow is confused with influence direction.View in phase
- Examine relationship patternsPatterns become decorative labels without agreement.View in phase
- Risks and next modellingThe map immediately triggers a large redesign.View in phase
Trap
Bound contexts
Symptom
Every microservice becomes a bounded context without examination.
What to do
Compare model meanings and justify boundaries in domain terms.
Trap
Ownership and current state
Symptom
Desired architecture hides current dependencies.
What to do
First map contracts and responsibilities actually in use.
Trap
Label dependencies
Symptom
Data flow is confused with influence direction.
What to do
Label both perspectives separately and check with the teams.
Trap
Examine relationship patterns
Symptom
Patterns become decorative labels without agreement.
What to do
Clarify consequences for changes, translation and coordination per pattern.
Trap
Risks and next modelling
Symptom
The map immediately triggers a large redesign.
What to do
First test the highest-risk assumption against a business case.
08
Stop criteria
When to pause, resolve prerequisites, or choose another approach
Mark unresolved boundaries or missing team representation as hypotheses; do not derive binding interface commitments from them.
Finished the method guide?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.