DDD (Domain-Driven Design) is a software design approach that puts the business at the center: the code faithfully reproduces the concepts, rules and vocabulary of the domain (insurance, logistics, payments), built in close dialogue with domain experts. The approach was formalized by Eric Evans in a book published in 2003.
Two ideas are at its core. The ubiquitous language: developers and experts use the same words, and those words appear in the code. Bounded contexts: a large system is split into coherent zones, each with its own model; a "customer" does not mean the same thing for billing and for support.
DDD also offers tactical building blocks (entities, aggregates, value objects, domain events). It is useful for software with high business complexity and often serves as a guide for splitting an application into microservices.
Why it matters when hiring
Many developers mention DDD; few have applied it beyond naming folders. In an interview, ask how the candidate identified the bounded contexts of a project and how they worked with domain experts. The strong signal: they talk about the business before talking about patterns. It is a key skill for an architect or tech lead on complex business software.