Domain-driven design (DDD) is a software development philosophy centered around the domain, or sphere of knowledge, of those that use it. The approach enables the development of software that is focused on the complex requirements of those that need it and doesn’t waste effort on anything unneeded. The clients of domain-driven design are often enterprise-level businesses.
To design from a domain-driven perspective, the business's area of expertise or domain must be defined. There are supporting and core domains. The core domain of a business is unique and central to its operation, therefore receiving the majority of attention, time and resources in the development process. The supporting domains are more general such as money, service or time. These domains are then modelled out in language and then in corresponding code. If a domain can’t be easily defined in language, it is not ready to be coded. If a change is made in a domain of business, a corresponding change in the code would generally be required.
The book Domain Driven Design by Eric Evans introduced the philosophy. Domain-driven design draws on object-oriented analysis and design. The approach eases communication about the project at hand and limits focus on needs central to the domain. At the same time, domain-driven design requires extensive knowledge of a domain and is poorly suited to highly technical projects.