A company decides to fulfil an order in several shipments. Its architecture already separates sales, warehouse operations and billing. Interfaces and owners exist. Then a disagreement appears: “shipped” means one consignment to the warehouse but completion of the whole order to billing. Adding another status does not decide which fact should allow an invoice to be issued.
Context Mapping makes these relationships between models explicit. A Bounded Context identifies where a model has a consistent meaning. A context map shows dependencies between those areas, where meanings are translated and who can influence a change. It is not a diagram of where servers run.
A request arrow does not tell the whole dependency story
Sales calls the warehouse API, but that call says little about the teams' freedom. If the warehouse changes what shipment means and sales must adapt, the warehouse is upstream in that relationship. The consumer is downstream. These terms describe influence over the model and contract, not the importance of departments.
The same participants may have different roles in another relationship. Sales might define the confirmed order that authorises picking. Avoid assigning one system a universal “master” position. Name the particular dependency. Martin Fowler's discussion of Bounded Context explains why different models need explicit relationships.
Start with what happens today, including awkward shortcuts. If billing reads warehouse tables directly and changes are discussed only after failures, that matters more than a proposed future API. Draw the target separately; mixing present and future hides the work required to move between them.
What influence does the consumer really have?
A Customer/Supplier relationship means downstream needs influence the supplier's planning, not merely that data changes hands. For partial shipping, billing needs an agreed delivery date for consignment information and checks that establish whether it can use the new contract. The Context Mapper documentation describes the relationship vocabulary.
If neither side can deliver a useful capability without the other, acknowledge a partnership and manage the change together. That is more honest than two independent plans that both treat the neighbour's work as already finished. Coordinated planning does not require sharing the entire internal model.
An external carrier may offer a different relationship: our requests do not determine its roadmap. We can deliberately adopt its model, the Conformist option, when that suits the product. Or we can retain our own model behind an Anti-Corruption Layer. Translation has an operating cost, so buy independence for a meaningful difference rather than for the pattern name.
A map does not create negotiating power. Labeling a connection Customer/Supplier does not turn an unconfirmed delivery date into a commitment. Someone must agree on scope, timing and how conflicting priorities will be resolved.
Record meaning, not just fields
For partial shipping, agree on what crosses the boundary: a consignment, order lines, quantities and the point of handover. Can that fact be corrected? What does cancellation mean after goods have physically left? An identical status string does not guarantee an identical interpretation.
Use examples: the first consignment leaves, the second is delayed, information about the first is corrected. Which billing document appears, what does the customer see and who explains the discrepancy? Ownership of a shipment fact is not automatically ownership of invoicing policy. Connect those responsibilities without merging them.
With many consumers, a supplier can offer a stable interface and a documented exchange language instead of building a bespoke representation for every neighbour. That language need not expose every internal warehouse object. Published Language describes a boundary agreement, not a universal company-wide model.
The relationship does not dictate transport. Translation can happen within one application, and consumers can verify an agreement without introducing a broker. Conversely, two deployed services can remain tightly coupled through their model. Record the implementation beside the relationship without treating them as the same decision.
The map also matters when data does not arrive
Team relationships affect recovery as well as releases. When consignment information is late, billing might remain in a provisional state. Another scenario may need an authoritative check before proceeding. Acceptable delay follows the promise to the customer; selecting an event transport does not decide it.
A corrected shipment raises further questions. Who publishes the correction? Who recalculates the result? Which completed actions need a separate remedy? A new event does not recall a document already sent. Mark the responsible parties on the map and keep the detailed recovery agreement with the contract.
Not every requirement warrants continuous integration. A periodic, agreed report may be sufficient for a separate task, without synchronising all objects in both directions. That report is still a data transfer with responsibilities, however. Calling it “no relationship” would hide a real dependency rather than remove one.
Test a change, not the completeness of the diagram
Begin with the three participating contexts rather than every table in the estate. Identify model owners, important facts, exchange mechanisms and actual negotiating relationships. Make unanswered questions visible, such as who can approve a changed interpretation of a status.
Then walk partial fulfilment through the proposed contract. Contract tests can verify concrete consumer expectations against provider behaviour. They supplement business examples rather than replace them: a compatible payload can still carry a misunderstood fact.
The discussion should establish what must change jointly, what remains local and which promises are not yet confirmed. Update the map with those decisions. If it only appears at an annual architecture review, the real working agreements are probably being maintained somewhere else.