In a growing company, the same word often stops meaning the same thing everywhere.
Sales sees a customer as an account and contacts. Billing sees a payer and contract. Support sees users, incidents, and service history. Product may see subscriptions, entitlements, and behavior.
Trying to force all of those meanings into one universal model usually produces a shared object that becomes harder to change with every new requirement.
What is a Bounded Context?
In Domain-Driven Design, a Bounded Context is an explicit boundary inside which a model and its language are consistent.
Inside one context, “customer,” “order,” or “product” has a specific meaning. Another context may use the same word differently because it solves a different business problem.
The point is not to eliminate duplication. The point is to prevent one model from pretending that every part of the business has identical rules.
Bounded Context is not the same as a microservice
A context is a business and semantic boundary. A microservice is a deployment and technical boundary.
One Bounded Context can live inside a modular monolith. A large context may later be implemented by several services. Splitting software into services does not automatically create good domain boundaries.
If every service still reads the same tables, shares the same model, and needs coordinated releases, the company has distributed deployment without gaining much independence.
How do you find a useful boundary?
I would start with disagreement and change, not with tables.
Useful signals include:
- the same term means different things to different business groups;
- one area changes for reasons that rarely affect another;
- different teams own different business outcomes;
- rules are repeatedly full of exceptions such as “except for billing” or “only for enterprise customers”;
- one shared model has become a coordination point for many teams;
- data ownership is unclear because everybody can modify the same records.
A good boundary tends to contain rules that change together and separates rules that change for different reasons.
Business language is an architecture signal
Technical teams often look for boundaries in code first. Business conversations can expose them earlier.
If two departments use the word “order” but argue constantly about its lifecycle, they may not actually be describing one concept. One could mean a commercial commitment, another a warehouse task, and another a financial transaction.
Making those meanings explicit is often more valuable than creating another generic enterprise data model.
What does the business gain?
Changes stay local more often. A finance rule should not require redesigning sales and fulfillment unless the business relationship actually changed.
Ownership becomes clearer. A context can have an owner for its rules, priorities, and data instead of every important change becoming a cross-company negotiation.
Teams can move at different speeds. A fast-changing product area does not necessarily need to coordinate every release with a stable accounting area.
The business value is not architectural elegance. It is lower coordination cost.
What happens to data?
Once boundaries become real, one database can no longer automatically be treated as a shared memory for the whole company.
Each context should have clear ownership of the facts it controls. Other contexts consume those facts through explicit contracts: APIs, events, replicated read models, or another agreed interface.
This does not require a separate physical database on day one. It does require a rule about who is allowed to change which data.
That is why Bounded Context and shared-database decisions are closely related: a shared database becomes dangerous when it destroys ownership boundaries.
How do contexts communicate?
Contexts need contracts because business processes rarely stop at one boundary.
A sales context may create a commercial agreement. Billing needs enough information to invoice. Fulfillment needs enough information to deliver. They do not necessarily need each other’s entire internal model.
Good contracts expose the information needed for cooperation without exporting every internal detail.
What does a bad boundary look like?
Too large: many unrelated rules and teams still collide inside one context, so the boundary does not reduce coordination.
Too small: every business action crosses several contexts, creating constant network calls, events, mapping, and distributed transactions.
Based only on the org chart: organizations change. A temporary reporting structure is not always a durable business boundary.
Based only on entities: “customer service,” “order service,” and “product service” can recreate the same universal-model problem across the network.
When should a company not overdo DDD?
A small product with one team and a simple domain may need clear modules, not a large Bounded Context exercise.
Domain decomposition pays off when coordination, ambiguous ownership, and conflicting business rules are already meaningful problems. Adding formal boundaries before that can turn a simple system into distributed ceremony.
Questions to ask
- Where do the same words mean different things?
- Which rules usually change together?
- Which changes require too many teams to coordinate today?
- Who owns each business fact?
- Which data must cross a boundary, and which data only crosses because everything is shared?
- Can one team change its context without coordinating a release with several others?
- Would this boundary still make sense if the org chart changed?
In the end
A Bounded Context is not a prettier way to divide code. It is an agreement about where one business model ends and another begins.
The right boundary makes change cheaper because fewer people, systems, and rules need to move together. If the boundary increases coordination instead, it is probably in the wrong place.