DDD Context Map Template

Map bounded contexts and their DDD relationships (ACL, OHS, conformist, shared kernel), team ties and evolution plan

架构与系统设计标准Domain-Driven Design context mapping patterns (Evans)context map更新于 2026年10月20日

使用方法: Use it to expose integration and team problems across a domain before a re-org, migration or platform change. Draw the as-is map with honest upstream/downstream directions first. The main pitfall is recording only technology (REST, Kafka) instead of the model and team relationship.

预览

Context Map: [Domain or product area]

Map of the bounded contexts in one domain and the relationships between them: who depends on whom, which Domain-Driven Design integration pattern governs each relationship, how the teams cooperate and how the map should evolve. Based on the context mapping patterns of Domain-Driven Design (Eric Evans) and common practice. Replace every [bracketed] value and every row marked Example. Worked examples use an online grocery retailer.

Field	Value
Domain / scope	[Online grocery: ordering, fulfilment, payments]
Map type	[As-is / To-be / Both]
Version	[0.1]
Status	[Draft / Agreed / Superseded]
Owner	[@domain-architect]
Contributors	[@team-leads]
Related documents	[Bounded context canvases], [EventStorming summary], [ADRs]
Last updated	YYYY-MM-DD

1. Scope and purpose

[Scope statement. Example: This map covers the eight bounded contexts involved from basket to doorstep. It supports the decision to replace the legacy order management system and to split the Fulfilment team in two.]

2. Pattern reference

Pattern	Abbrev.	Meaning in this map
Partnership	P	Two teams succeed or fail together and coordinate planning of shared features
Shared kernel	SK	Two contexts share a small, explicitly agreed part of the model and code; changes need both teams' consent
Customer-supplier	C/S	Upstream supplier plans with the downstream customer's needs in mind; the customer has a say in priorities
Conformist	CF	Downstream adopts the upstream model as is, because it has no influence over it
Anticorruption layer	ACL	Downstream translates the upstream model into its own, protecting its language
Open host service	OHS	Upstream offers a well-defined protocol or API that serves many consumers
Published language	PL	A documented, shared exchange format (schema, standard) used across the relationship
Separate ways	SW	No integration; each context solves its need independently
Big ball of mud	BBoM	A part of the system with mixed models and no clear boundary; contain it rather than spread it

3. Bounded contexts

ID	Context	Classification	Owning team	Main responsibility	Canvas
BC-01	Example: Catalogue	Supporting	Team Range	Products, prices shown to shoppers, availability flags	[Link]
BC-02	Example: Basket and Checkout	Core	Team Checkout	Basket rules, substitutions preferences, order placement	[Link]
BC-03	Example: Slot Booking	Core	Team Slots	Delivery slot offers and capacity	[Link]
BC-04	Example: Fulfilment	Core	Team Fulfilment	Picking, substitution, van loading	[Link]
BC-05	Example: Payments	Generic	Team Payments	Authorisation, capture, refunds via payment provider	[Link]
BC-06	Example: Legacy OMS	Big ball of mud	Team Platform	Order state, invoices, customer service screens	n/a
BC-07	Example: Payment provider	External	Vendor	Card processing	n/a
[BC-NN]	[Context]	[Core / Supporting / Generic / External]	[Team]	[Responsibility]	[Link]

4. Context map diagram

The diagram below shows the as-is relationships; arrows point from upstream to downstream.

5. Relationship register

ID	Upstream	Downstream	Upstream pattern	Downstream pattern	Mechanism	Pain or risk
REL-01	Example: Catalogue	Basket and Checkout	OHS + PL	Conformist	REST API, JSON schema `product.v2`	Price changes during checkout cause basket recalculation
REL-02	Example: Slot Booking	Basket and Checkout	Partnership	Partnership	Events `SlotReserved`, `SlotReleased`	Joint releases needed for slot changes
REL-03	Example: Basket and Checkout	Fulfilment	Supplier	Customer	Event `OrderPlaced` on message broker	Fulfilment needs fields that are not yet in the event
REL-04	Example: Legacy OMS	Fulfilment	None (no influence)	ACL	Nightly database export, translated by adapter	Data is up to 24 hours stale
REL-05	Example: Payment provider	Payments	OHS + PL	ACL	Provider SDK and webhooks	Provider model leaks into refund logic
REL-06	Example: Fulfilment	Basket and Checkout	Shared kernel	Shared kernel	Shared library `substitution-rules`	Version drift between teams
[REL-NN]	[Context]	[Context]	[Pattern]	[Pattern]	[Mechanism]	[Pain]

6. Team relationships

Relationship	Teams	How they cooperate today	Healthy?	Action
REL-02	Example: Team Slots and Team Checkout	Joint planning every two weeks, shared Slack channel	Yes	Keep
REL-03	Example: Team Checkout and Team Fulfilment	Fulfilment raises tickets; prioritised quarterly	No	Move to monthly customer review of the `OrderPlaced` contract
REL-04	Example: Team Platform and Team Fulfilment	No regular contact	No	Name an OMS contact; plan strangler migration
[REL-NN]	[Teams]	[Cooperation]	[Yes / No / Partly]	[Action]

7. Integration details

Relationship	Contract	Contract owner	Translation owner	Versioning	SLA / freshness
REL-01	Example: `catalogue-api` OpenAPI	Team Range	None (conformist)	URI major version, 6-month deprecation	p95 120 ms, 99.9%
REL-03	Example: `OrderPlaced` event schema v3	Team Checkout	Team Fulfilment	Schema registry, backward compatible	Delivered within 5 s
REL-04	Example: OMS export file	Team Platform	Team Fulfilment (ACL)	None	Daily at 02:00
[REL-NN]	[Contract]	[Team]	[Team]	[Policy]	[SLA]

8. Evolution plan

The target map changes three relationships.

ID	Change	From	To	Reason	Decision / ticket	Target date
EV-01	Example: Replace OMS export with events	BBoM + ACL	OHS + PL from new Order context	Stale data causes missed substitutions	ADR-031	YYYY-MM-DD
EV-02	Example: Dissolve shared kernel for substitution rules	Shared kernel	Customer-supplier, Fulfilment upstream	Teams release on different cadences	ADR-034	YYYY-MM-DD
EV-03	Example: Add ACL in Basket for catalogue model	Conformist	ACL	Catalogue model change broke checkout twice	[Ticket]	YYYY-MM-DD
[EV-NN]	[Change]	[Pattern]	[Pattern]	[Reason]	[Link]	YYYY-MM-DD

The to-be diagram shows the end state after EV-01 to EV-03.

9. Risks and open questions

ID	Risk or question	Owner	Mitigation or next step
R-01	Example: New Order context needs OMS invoice logic that nobody fully understands	@platform-lead	EventStorming session on invoicing before EV-01 starts
R-02	Example: Payments vendor change would require a new ACL	@payments-lead	Keep provider types out of the Payments domain model
[R-NN]	[Risk]	[@owner]	[Mitigation]

Standard and licence note

Based on the strategic design and context mapping patterns of Domain-Driven Design (Eric Evans, Domain-Driven Design, 2003, and his later Domain-Driven Design Reference, which adds the partnership pattern). The pattern names are industry terms; all text, tables and examples here are original to this collection. Template licence: MIT.