Chapter 1. Why Domain-Driven Design

The software industry appeared back in the early 1960s and is growing ever since. We have heard predictions that someday all software would be written and we will not need more software developers, but this prophecy has never become a reality, and the growing army of software engineers is working hard to satisfy continually increasing demand.

However, from the very early days of the industry, the number of projects that were delivered very late and massively over budget, plus the number of failed projects is overwhelming. The 2015 CHAOS Report by Standish Group (https://www.projectsmart.co.uk/white-papers/chaos-report.pdf) suggests that from 2011 to 2015 the percentage of successful IT projects remains unchanged on a level of just 22%. Over 19% of all projects failed, and the rest have experienced challenges. These numbers are astonishing. Over four decades a lot of methods have been developed and advertised to be a silver bullet for software project management, but there is no or little change in the number of successful projects.

One of the critical factors that define the success of any IT project is understanding the problem, which the system to be designed, suppose to solve. We all very familiar with systems that do not solve problems they claim to answer or do it very inefficiently. Understanding the problem is also one of the core principles of the Lean Startup methodology, proposed by Eric Ries in his book The Lean Startup by Crown Publishing. Both Scrum and XP software development methodologies embrace interacting with users and understanding their problems.

Domain-Driven Design (DDD) term was coined by Eric Evans in his now-iconic book Domain-Driven Design: Tackling Complexity in the Heart of Software by Addison-Wesley back in 2004. More than a decade after the book was published, interest in practices and principles, described in the book, started to grow exponentially. Many factors influence such growth in popularity, but most important one is that DDD explains how people from software industry can build an understanding of their users needs and create software systems, which solve the problem and make an impact.

In this chapter, we will discuss how understanding the business domain, building domain knowledge, and distinguishing essential complexity from accidental complexity, can help in creating software that matters.

The objective of this chapter is to understand:

• Problem space versus solution space
• What went wrong with requirements
• Understanding complexity
• The role of knowledge in software development