Domain-Driven Design

Domain-Driven Design centers development on programming a domain model that has a rich understanding of the processes and rules of a business domain. Eric Evans introduced the term and the conceptual framework in his 2003 book. The premise is direct: in most complex applications, the hard problem is not the technology. It is the domain itself — the activity or business the software serves.

DDD responds to that premise with three commitments. You put the core domain and its logic first. You base every design decision on a shared model of that domain. You treat modeling as an ongoing, creative collaboration between developers and domain experts, not a one-time diagram handed to engineering.

Ubiquitous Language: one vocabulary, enforced in code

A Ubiquitous Language is a shared vocabulary that developers and domain experts build together, grounded in the domain model. It has to be precise, because software tolerates no ambiguity the way conversation does.

Use this language everywhere: in code, in conversations with domain experts, in documentation, in tests. When a domain expert uses a term you have not modeled, or objects to a term your code uses, that is signal. Evans frames it as a two-way obligation — domain experts should object to terms that are awkward or inadequate, and developers should watch for ambiguity or inconsistency that will trip up the design. The language evolves as your understanding of the domain deepens.