A bounded context defines where one domain model and its language apply. Inside the boundary, terms, identifiers, rules, and ownership should be consistent. Outside it, another part of the business may represent the same real-world thing differently because it uses that thing for a different purpose.
Why one model is not always enough
A legacy application may use a single record across sales, billing, support, and reporting. Each area can need different fields and rules. Treating that record as one universal model makes a change for one area affect all the others.
| Question | What it reveals | Boundary signal |
|---|---|---|
| What does this term mean here? | Local business language | Meanings differ across areas |
| Who changes this rule? | Decision ownership | Separate owners or policies |
| Which data is authoritative? | Source of truth | Distinct write responsibility |
| What changes together? | Cohesion | Stable groups of behaviour |
A bounded context accepts that models can differ. The integration between them then becomes an explicit contract rather than an accidental use of shared internals.
Finding contexts in legacy code
Folder names rarely provide enough evidence. The current structure may follow technical layers, former team boundaries, or a framework's conventions. A legacy codebase audit combines code evidence with the language used by people who operate the system.
The mapping work includes:
- Trace business workflows. Follow a task from its entry point through rules, storage, and external calls.
- Record vocabulary. Note where the same word carries different fields, states, or decisions.
- Locate write ownership. Identify which code is allowed to create or change each record.
- Inspect change history. Find code that repeatedly changes for the same business reason.
- Mark integrations. Document calls and data movement between proposed contexts.
The result is a hypothesis that the team validates against real behaviour. It is not derived from class counts or database tables alone.
From context to code boundary
A bounded context is a model boundary, not a required deployment style. It can become a module inside a modular monolith or support one or more separately deployed services. The choice depends on release, scaling, reliability, and ownership needs.
Where contexts interact, the contract should name the data and behaviour being exchanged. An Anti-Corruption Layer can translate when a new context must work with a legacy model whose terminology and rules should not spread into the new design.
What an audit records
A legacy codebase audit documents each proposed context, its language, owned data, public operations, callers, and dependencies. It also marks unresolved areas where ownership is shared or the same rule appears in several places.
That map guides refactoring order. A team can strengthen an internal boundary before service extraction, or keep it inside the monolith when independent deployment has no clear purpose. The bounded context supplies the semantic boundary; the migration plan decides how and when the software boundary changes.
