# Origins & Definitions ## What is Domain Driven Design? Domain Driven Design, is initially the title of a [[3. Publish/Software Excellence Cookbook/Essentials/Domain-driven Design/Books|book]] written by Eric Evans in 2003. The book, referred as the Blue Book, has started the DDD movement, that grew during the 20 following years, in order to assist Product Development teams building softwares operating in complex domains. Eric Evans gives this definition: > Domain-driven design is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book presents an extensive set of design practices, techniques and principles. In other words, it is a combination of design techniques, joined to processes, aimed at building higher quality softwares. ## Should I use DDD? The definition gives a first prerequisite to the use of DDD: It is a practice to handle complex domain. If your software is not dealing with complex domains, you are wasting your time. A simple CRUD application would do the job. Vaughn Vernon, in his popular [[3. Publish/Software Excellence Cookbook/Essentials/Domain-driven Design/Books|Implementing Domain-Driven Design]], also known as the Red Book, gives a framework to help you decide if DDD is the right tool for your need in the first chapter. A second prerequisite, from my experience, missed by most teams that get passionated about the buzz surrounding DDD, is to master the fundamentals of software design. There is no Domain-Driven Design, if there is no ability to create a design. The recommandation is to have experience and to understand the OOP principles, even though, Functionnal Programming can work as well. [[3. Publish/Software Excellence Cookbook/Essentials/Domain-driven Design/Books|Domain Modeling Made Functionnal]] discuss how DDD applies to FP. Behind DDD, there is the concept of expressing your complex domain into your code, through an iterative process. As you deepen your understanding, you let new concepts emerge and you model them, by _refactoring towards deeper insights_. Iterations can only happen if your team operates in a truly agile environment, far from the waterfall process, where you are asked to design upfront. The agile recipe does not matter, but you can learn more [[3. Publish/Software Excellence Cookbook/Essentials/(true) Agility & LEAN/Index|about it]].