A set of guiding principles that together form a mindset about building software, often abbreviated as DDD. The concept was introduced by Eric Evans, and the original textbook was published in 2003. The Domain Driven Design perspective is not reductionist, but rather embraces the notion that software development is part of a much larger and complex socio-technical system. As a result, many practices for managing the complexities of software development, like Event Storming, Behavior Driven Development, and Domain Story Telling, have their roots in the DDD community. The stated principles of Domain Driven Design are principles are:
The words in bolded, italic text above is part of the DDD terminology, which while central to understanding the mindset, is often an times is an Achilles heel.
Domain Driven Design:
The corollary to the above is the Domain Driven Design is overkill when working on simple domains or simple pieces of software. Only use it if you have complexity to manage.