A meeting ends with agreement: blocked customers must not create orders. Sales understands a block as a restriction on new business because of unpaid invoices. Support understands it as suspension of a user account. The shared customer record has one field called blocked. The difference stays hidden until a financial restriction unexpectedly removes access to an already paid-for product.
Another universal status is unlikely to solve that problem. A Bounded Context defines where a model and its language are consistent. Outside that boundary, the same person or organisation may participate in a different model. Those differences need deliberate translation, not a shared object accumulating exceptions.
One organisation, several different questions
Sales needs contacts, opportunities and commercial terms. Billing needs a payer, invoices and settlement. Support needs users, active services and cases. These facts concern related parties, but need not form one entity that every team modifies in the same way.
One buyer may pay for several subsidiaries, while the person using the product may not be the payer at all. Identifiers therefore do not always map one to one. A common identifier can help connect records without erasing different roles and rules.
Martin Fowler's description of Bounded Context explains boundaries through these differences in models and language. It is not an argument against shared reference data. It is a reason not to make one object answer questions whose meanings differ across the company.
A model boundary is not necessarily a department or a service
The finance department is not automatically one context. It may apply quite different rules to invoicing and staff remuneration. Conversely, one model may serve people across departments. The organisation chart helps identify people to consult; it does not substitute for understanding the work.
Nor should every class or table become a context. Ask which decisions and constraints must remain coherent. If debt assessment and permission to enter a commercial commitment are repeatedly discussed together, recognise that relationship rather than splitting it to produce equally sized modules.
A Bounded Context also differs from a microservice. One defines a model's scope; the other is a separately deployable technical component. A context can exist in a modular monolith or involve several components. Adding network calls does not create good semantic boundaries. The Azure Architecture Center domain analysis guidance connects business modelling with service design.
Share the fact without exporting every internal rule
Return to the customer. Billing might publish that a restriction on new commercial commitments has taken effect. Sales uses that fact under an agreed rule. Support should not automatically disable accounts; it needs to understand which existing entitlements are actually affected.
A good event name helps but is insufficient. The agreement includes the reason, party identifiers, effective time, removal of the restriction and correction of mistakes. Consumers need to distinguish a current restriction from one belonging to a completed period.
Sometimes an external system only exposes an awkward generic status. A translation boundary can map it into the local model without spreading foreign assumptions through the code. The Anti-Corruption Layer pattern addresses this concern. Renaming blocked to isAllowed while losing the reason is not an adequate translation.
Who may change each fact?
Instead of debating who owns the customer, list the facts. Who confirms debt settlement? Who assigns a user to an organisation? Who determines whether a subscription is active? Ownership of one fact does not confer authority to edit everything known about the party.
The data may initially remain in one database. What matters is preventing unagreed writes into another model's area. If sales can bypass billing and directly change the debt flag, the boundary only exists in the diagram. Moving to separate servers would carry the same conflict into an API.
A report can combine views from several contexts. It should not quietly become another place to edit the underlying facts. Users benefit from knowing the source and freshness of a measure. A shared database and a shared model are related but distinct decisions.
Independent models do not permit contradictory promises
If sales must check a financial restriction before confirming a transaction, agree on how current the information must be. Asynchronous events can lag. Depending on the risk, the process may need an authoritative check, a provisional agreement state or another explicit mechanism. The word context does not choose that mechanism.
Recovery also crosses boundaries: reverse an incorrect restriction, communicate the correction and identify decisions made using the earlier state. Each team may own its code, but customers should not have to discover which two models lost their decision between them.
Context owners need agreements about contract versions and transition times. They need not be different people for every module. A small team can hold several responsibilities while keeping ownership of meaning and change explicit.
Try the boundary against the next change
Take several recent changes and identify the rules that genuinely had to move together. Then consider a new requirement: one payer can support several independent organisations. Which model changes, which facts must be shared, and which existing operations should remain unaffected?
If a small amendment requires every component to ship together, reconsider the boundary. It may be too narrow, or a shared object may still couple apparently separate modules. Correcting this inside a monolith can be cheaper than immediately extracting services.
The useful outcome is a set of definitions, fact owners and agreements about transitions. For this customer, it should be clear who blocked new business, why an already paid-for service remains available and which fact lifts the restriction. Choosing the technical form of separation becomes much easier once those questions have answers.