Skip to content
Software Architecture Guide

Reflecting the Business Domain in the Architecture

Explanation

Section titled “Explanation”

A software system serves a business. If its names and structure follow the business domain, people on both sides understand each other more easily.

Share one language. The team and the domain experts agree on a common vocabulary (see Ubiquitous Language). Domain experts act as a check. They object when a term or structure poorly conveys what they know about the domain. The language is not fixed. It should change as the team’s understanding of the domain grows, and the model should change with it.

Watch for words with several meanings. Terms such as Customer and Product often mean different things to different stakeholders. This confusion comes back again and again. Finding these differences early, and writing them down, keeps misunderstandings out of the design.

Do not force one model on a big domain. The larger the domain, the harder it is to build a single unified model. Bounded contexts address this. A bounded context (see Bounded Context) is a central Domain-Driven Design pattern for structuring systems around the domain.

Link structure to teams. Bounded contexts also group people around a subject matter. That lets the organization line up with the flow of value. This connects to Conway’s law. The law matters because human communication enables software coupling. So it should influence how teams are organized.

Example

Section titled “Example”

A retailer’s sales team uses “Customer” for a person who has placed an order. The billing team uses “Customer” for whoever pays the invoice. A discussion between both teams and the domain experts surfaces this difference. The team defines a Sales context and a Billing context. Each context defines “Customer” in its own terms and records that definition in a shared glossary.

Trade-offs

Section titled “Trade-offs”

Several contexts mean several models and several meanings of one word. Teams must then make those differences explicit, which takes ongoing effort. A single unified model avoids that effort. But it gets harder to build as the domain grows. Evolving the language also means names and models change over time, so documents need updating.

Checks

Section titled “Checks”
  • Names of building blocks and terms in the documentation use the vocabulary of the business domain, and domain experts have reviewed them.
  • Terms that stakeholders understand differently, such as Customer or Product, are identified and their meanings are written down.
  • The domain is split into bounded contexts instead of one single unified model.
  • The document shows how the shared language and model are updated as understanding of the domain grows.
  • Team organization is aligned with the bounded contexts, taking Conway’s law into account.
Section titled “Related”

Sources

Section titled “Sources”