# Bounded Context

> An explicit boundary within which one domain model and its language have a consistent meaning.

- HTML version: https://robbiepalmer.me/ideas/bounded-context
- Source: https://martinfowler.com/bliki/BoundedContext.html

A bounded context defines where a domain model applies. Inside the boundary, terms, rules, and
assumptions should have one consistent meaning. Outside it, another model may use the same words
differently.

The boundary makes disagreement manageable. "Customer" can mean the person receiving an order in
one context and the account responsible for payment in another. Neither definition needs to become
universal. A context map records how the models relate and where translation belongs.

Bounded contexts are part of [Domain-Driven Design](/ideas/domain-driven-design). They do not have to
match microservices, databases, or teams one for one. Those boundaries often align because
[Conway's Law](/ideas/conways-law) pulls architecture towards communication paths, but treating the
org chart as the model skips the domain work.

[Ontology Engineering](/ideas/ontology-engineering) can define concepts within a context and map
them to concepts elsewhere. The mapping should preserve differences instead of forcing every
context into one vocabulary.

## Questions it prompts

* Where does the meaning of an important term change?
* Which rules must remain consistent together?
* What must be translated when information crosses the boundary?
* Does the team that owns the model have authority to change and operate it?

## Related ideas

- [Conway's Law](https://robbiepalmer.me/ideas/conways-law.md): The structure of a system tends to reproduce the communication structure of the organisation that built it.
- [Data Mesh](https://robbiepalmer.me/ideas/data-mesh.md): A decentralised approach to analytical data built on domain ownership, data products, a self-serve platform, and federated governance.
- [Domain-Driven Design](https://robbiepalmer.me/ideas/domain-driven-design.md): Model software around the language, rules, and boundaries of the problem domain.
- [Ontology Engineering](https://robbiepalmer.me/ideas/ontology-engineering.md): The practice of defining the concepts, relationships, constraints, and shared vocabulary needed to represent a domain.

## Where it appears

- Blog post: [The Philosophy of Data Science](https://robbiepalmer.me/blog/2022-03-02-the-philosophy-of-data-science.md)
- Blog post: [Uniting the Machine Learning and Data Streaming Ecosystems - Part 1](https://robbiepalmer.me/blog/2023-03-28-uniting-machine-learning-data-streaming-1.md)

---

Markdown index of this site: https://robbiepalmer.me/llms.txt