# Business Domain Understanding

**In short:** Business domain understanding means architects and stakeholders share one clear picture of the business and its terms. Where meanings truly differ, bounded contexts keep each meaning in its own place.

## Explanation

Business domain understanding is a shared picture of the business area a system serves. Architects and stakeholders build it together. The picture rests on common terms that everyone uses in the same way.

**Terms drift apart in large organizations.** Different groups use slightly different vocabularies. The same word can mean different things in different parts of the organization. Words like "Customer" and "Product" are typical examples. They have several meanings and cause confusion again and again.

**Language is a tool for testing understanding.**
- Domain experts should object when a term or structure feels awkward or inadequate. Their objections help test the model and build understanding.
- Developers should watch for ambiguity or inconsistency in the language. Such gaps can harm the design.
- The language and the model should change as the team learns more about the domain.

**When meanings really differ.** Domain-driven design (see Domain-Driven Design) divides a large system into bounded contexts. Each bounded context can have its own unified model, so a term keeps one clear meaning inside it. See Bounded Context for details.

**Where to record it in arc42.** The arc42 glossary (see arc42 Glossary) lists the most important domain and technical terms stakeholders use when they discuss the system. The business context treats domain interfaces as critical. All stakeholders should understand the data the system exchanges with its environment (see arc42 Context and Scope).

## Example

A company has a sales team and a billing team. Both say "Customer". For sales, it means a person who might buy. For billing, it means a party with a signed contract. The architect notices the gap when the two groups describe the same system. The team splits the system into two bounded contexts, each with its own definition of "Customer". They write both meanings in the glossary.

## Trade-offs

Keeping several meanings of one term, each in its own bounded context, avoids forced agreement. It also means the team must manage more than one model and name each one clearly. The language and model keep changing as understanding grows, so the glossary needs regular updates.



## Checks

- The glossary lists the key domain and technical terms that stakeholders use when discussing the system.
- Terms with several meanings, such as Customer or Product, are identified and explained.
- Where meanings differ between parts of the organization, the document separates them into bounded contexts.
- The business context describes the domain interfaces and the data exchanged with the environment in a way all stakeholders can understand.

## Related

- [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md)
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md)
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- [arc42 Glossary](https://arc.fuet.ch/concepts/documentation/arc42-glossary.md)
- [arc42 Context and Scope](https://arc.fuet.ch/concepts/documentation/arc42-context-and-scope.md)
- [System Idea and Vision Elements](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea-and-vision-elements.md)
- [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md)

## Sources

- [Bounded Context](https://martinfowler.com/bliki/BoundedContext.html) — martinfowler.com, accessed 2026-11-09
- [Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html) — martinfowler.com, accessed 2026-11-09
- [12 - Glossary | arc42 Documentation](https://docs.arc42.org/section-12/) — docs.arc42.org, accessed 2026-11-09
- [3 - Context and scope | arc42 Documentation](https://docs.arc42.org/section-3/) — docs.arc42.org, accessed 2026-11-09