Ubiquitous Language
A shared vocabulary used identically by domain experts and in the code, so that translation between business and implementation is unnecessary.
The practice in domain-driven design with the highest return and the lowest cost, and the one most often skipped in favour of tactical patterns.
The rule is literal: if the business says "policy lapses", the code says lapse(), not
setStatusInactive(). Every translation between the business's words and the code's words is a place
where meaning is lost and bugs originate — usually silently, because both sides believe they are
discussing the same thing.
What it produces beyond readable code: conversations with domain experts that surface misunderstandings early, because an expert can follow a description of the model; and a model that reflects how the business actually reasons rather than how a developer initially guessed.
The critical qualification: a ubiquitous language is ubiquitous only within a bounded context. "Customer" in billing, support and marketing are genuinely different concepts with different attributes and lifecycles. Forcing one shared definition across contexts produces a model that fits none of them, and that attempt is the origin of many over-general shared domain models.
Where the terms differ across contexts, the divergence is a boundary signal — and the translation between them belongs in an explicit mapping, not in an assumption that the words mean the same thing.