domain language — bounded contexts
Bounded contexts — where the language changes
Most systems are built from multiple services — separate parts of the system, each responsible for one job, that communicate through defined interfaces (APIs). The billing service handles charges. The notification service sends emails. Each has its own code, data, and language.
Domain language is not universal across these services. A subscription in the billing context and a subscription in the notification context may share a name but mean different things — one is a payment relationship, the other is a message preference. When two services use the same word with different meanings, integration bugs are structural, not accidental.
The DDD concept that resolves this is the bounded context — a boundary within which a term has exactly one meaning. At the boundary, translation happens explicitly: the billing service's subscription becomes the notification service's recipient through a defined mapping. The API contract from Volume III is where this translation lives. The contract is the boundary's documentation.
For the chain, the practical discipline is: when a term appears in two services, check whether it means the same thing. If not, the API contract must translate. If the contract doesn't translate, the ambiguity travels into the code and produces bugs that look like logic errors but are actually language errors.
Component composition — the frontend discipline
On the frontend, the design system — the shared library of reusable UI elements (buttons, inputs, cards, tables, modals) with rules for how they combine — enters the code as a component library. Each component is built once, documented once, and reused everywhere. The design system exists in two places: in Figma (where the designer works) and in code (where the developer works). The two must match — if they drift, the product has two sources of truth for how things look and behave.
The developer's interface to this library is Storybook (or an equivalent) — a browsable catalogue where every component appears in every state it can have, isolated from the application, clickable and testable independently.
The discipline: every component must exist in Storybook before it exists in the application. Every state the designer named in Figma gets a corresponding Storybook story. The catalogue and the Figma file are one-to-one — if they drift, the product has two sources of truth for how things look, and the visual regression tests catch the wrong baseline. A component that ships without a Storybook story is a component that cannot be visually regression-tested, cannot be browsed by the next developer, and has already begun to drift.