Customer-Supplier
The Supplier considers agreed requirements from the Customer; influence, priority and delivery are negotiated.
- CustomerRaises requirements with the upstream.
- SupplierAgrees on priorities and delivery with the Customer.
- CoordinationMakes the dependency and change path explicit.
Context
Why this is important
Manage dependencies between contexts cooperatively and define the Customer’s influence.
A relationship between Bounded Contexts in strategic Domain-Driven Design.
Customer-Supplier coordination
The shop remains a modular monolith with seven modules and a shared deployment; this relationship describes model ownership.
This is how you read the picture
- Customer Downstream
- Supplier Upstream
- Coordination Planning
| Aspect | Customer | Supplier |
|---|---|---|
| Role | Uses upstream capability | Provides capability |
| Change | Prioritises requirement | Plans delivery |
Benefits & limitations
Helps if:
- One context depends on another and can influence its evolution through agreed requirements.
- Both owners can discuss priorities and changes regularly.
Boundaries
- Customer influence is room for negotiation, not a delivery guarantee.
- If priorities remain misaligned, the Customer needs a different integration strategy.
In practice
- Identify upstream and downstream from actual data or capability dependencies. Record which dependency gives the Customer standing to raise requirements and prioritize them with the Supplier.
- Express the Customer’s needs as concrete contract or delivery changes. Both sides prioritize the work together based on business value, effort, and impact on other consumers.
- Agree on owners, feedback, compatibility checks, and an escalation path. After changes, verify that the Customer can still influence needed capabilities and that the contract remains reliable.
Read the detailed explanation
Customer-Supplier describes a cooperative relationship with a clear upstream and downstream. The Customer raises requirements that the Supplier can consider in planning. The relationship works when owners regularly prioritise and discuss effects on both models. Joint planning does not replace clear contracts: each context retains its business ownership.
The Customer can bring requirements to its upstream. A Context Map makes the relationship visible; each Bounded Context keeps its own model.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Who prioritises a requirement to the upstream?
View the solution with justification
Customer and Supplier coordinate it together.
ApplyingTransferred to a new situation
How can Ordering keep a product change compatible?
View the solution with justification
Teams agree on the reference, transition period and compatibility check.
EvaluateWeighing an alternative
When does this pattern fit if priorities remain opposed?
View the solution with justification
Effective cooperation is missing; the Customer should consider another relationship.
Explore further
These building blocks continue the thoughts of this page.
References
- Eric Evans · DDD Reference (opens in new tab)Primary reference on Context Mapping and relationship patterns.
- Vaughn Vernon · Implementing Domain-Driven Design (opens in new tab)Practical book on context boundaries and team relationships.
- Domain-Driven Design Reference · Strategic Design (opens in new tab)Terminology reference for strategic DDD.