Domain-Driven Design Terms

Domain-driven design, or DDD, gives teams a vocabulary for modelling business problems in software. The terminology matters because the hard part of DDD is rarely syntax. It is deciding where concepts begin and end, who owns which rules, and how to keep those rules legible in code.

Ubiquitous language and bounded context

Ubiquitous language means the team uses the same words in code, conversations, and documentation for the important business concepts. If operations says "shipment", finance says "order", and the code mixes both carelessly, misunderstanding is already encoded in the model.

A bounded context is the boundary within which a term has a precise meaning. "Customer" in billing may not mean the same thing as "customer" in support or identity. DDD does not force one universal model. It encourages clear boundaries so each model stays coherent.

Entity, value object, and aggregate

An entity has a stable identity that matters over time, even if its attributes change. An order remains the same order after its status changes. A value object is identified entirely by its attributes. A money amount or postal address is usually treated this way when equality depends on content rather than identity.

An aggregate is a cluster of related domain objects treated as a consistency boundary. One object, the aggregate root, controls access to the rest. The idea is to keep invariants enforceable without requiring the whole system to lock together at once.

Repository and domain service

A repository abstracts persistence for aggregates so the domain model is not littered with database concerns. It should feel like a collection of domain objects, not a generic dumping ground for every query imaginable.

A domain service holds domain logic that does not fit naturally on one entity or value object. It is for business rules that span concepts, not for arbitrary utility code.

Context mapping and anti-corruption

When bounded contexts interact, you need a context map: a view of how models relate and where translation is needed. An anti-corruption layer protects one context from another's model leaking in and distorting local concepts.

The practical point

DDD terms are useful only if they sharpen the model. They help teams choose consistency boundaries, name business concepts honestly, and stop technical structure from overpowering domain meaning. If the vocabulary becomes ceremony, the design has lost the plot. If it makes the rules of the business easier to express and change, it is doing its job.

This is why DDD tends to work best where the business rules are complex enough to deserve real modelling effort. In a thin CRUD application, the vocabulary can feel heavy. In a domain full of policy, exceptions, and evolving terminology, the same vocabulary can prevent expensive ambiguity from leaking into code and APIs.