What is Domain-Driven Design?

Eric Evans introduced the term in his 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software. Two decades and many practitioners later — Vaughn Vernon, Vlad Khononov, Alberto Brandolini — the core idea has only sharpened: software for a complex business should be organized around a deep, shared model of that business.

A working definition

Strip away the jargon and DDD rests on three premises:

1. For most software projects, the primary focus should be on the domain and its logic — not the database, the framework, or the UI.
2. Complex designs should be based on a model of that domain.
3. That model is best built through ongoing collaboration between domain experts and software people, expressed in a shared language.

Notice what's missing: no mention of microservices, event sourcing, or any specific tool. Those are options you may reach for later. DDD itself is the discipline of building and protecting a useful model.

The model is the project

A model is a selective simplification. A subway map is a model of a transit system: it deletes geography, scale, and street layout because none of that helps you ride the train. A useful domain model does the same — it keeps the concepts and rules that matter for the task at hand and discards everything else.

Crucially, in DDD the model is not a diagram you draw once and file away. It lives in three places at once, and they must stay in sync:

Ubiquitous language: the beating heart

The single most important practice in DDD is the ubiquitous language — one rigorous, shared vocabulary used by developers and domain experts alike, in meetings, in documents, and directly in the code. If experts say "a customer places an order," the code has a placeOrder() method, not insertOrderRecord().

This sounds trivial and is profoundly not. When language and code diverge, every conversation needs a mental translation step, and translation is where bugs and misunderstandings breed. A faithful ubiquitous language removes that translation entirely.

PlaceOrder — code that speaks the expert's language

// Reads the way a domain expert would describe it.
public final class Cart {

    public Order placeOrder(CustomerId customer, ShippingAddress address) {
        if (lines.isEmpty()) {
            throw new EmptyCartException();   // "you can't place an empty order"
        }
        return Order.from(this, customer, address);
    }
}

What DDD is not

Because the term gets stretched, it helps to state the boundaries plainly.