Introduction to Domain-Driven Design (DDD)

Domain-Driven Design (DDD) was introduced by Eric Evans in his 2004 book "Domain-Driven Design" (the "big blue book"). The article gives a high‑level overview of DDD, focusing on the questions "Why?" and "What?" while defining important terminology.

What is a domain? A domain is the scope of knowledge, influence, or activity; the subject area of a software application is its domain.

Why DDD? Software projects are complex mainly because of the domain itself. DDD helps address this core complexity by enabling teams to focus on solving domain‑related problems rather than building software for its own sake. It emphasizes that the software’s purpose is to empower users to solve domain problems, with all other functionality serving that goal.

What is DDD? DDD is not a specific technology but a set of concepts for building complex software. It can be summarized in three points:

Focus on the core complexity and opportunities of the domain.

Domain experts and software experts collaborate to explore a model.

Speak a ubiquitous language within a bounded context.

The article then expands each point.

Focus on the domain – concentrate on the domain’s core complexity, not merely on business features.

Explore the model – domain experts and developers work together to create an abstract representation that solves domain problems. A model is a simplified interpretation of reality that highlights relevant aspects while ignoring irrelevant details. It is not a diagram (e.g., ERD) but the concepts behind any visual representation.

Ubiquitous language – a shared language built around the domain model, used consistently in code, conversation, and documentation within a bounded context. A bounded context defines the limits (often a subsystem or team) where a particular model applies.

The article stresses that without a common language, developers and domain experts must constantly translate each other’s terms, leading to miscommunication and incomplete models.

Additional concepts and a visual overview of DDD are mentioned, with a promise to cover entities, value objects, and aggregates in future articles.

In conclusion, DDD remains a vital tool for handling software complexity, influencing many other practices and frameworks. The author invites feedback and provides links to further resources, including the original book, free reference material, and related talks.