When should you use DDD?

DDD works best when applied to large, complex systems. A surprising number of the systems Software engineers write today are basic CRUD (short for create, read, update, and delete) applications. Applying DD development to such applications would be overkill and likely make delivery slower and more complicated.

The Big Red Book provides a helpful DDD scorecard. Here is a simplified version of the scorecard:

Is your project . . .	Points	Additional thoughts
Mostly doing simple create, reads, updates, and deletes from the database?	0	Sometimes, evaluating simple can be tricky. If you have lots of business logic between the input and the output, your application might not fit into this category. If all you are doing is validating the input and then passing it through to the database layer, you are in this category.
Does your application have fewer than 30 user stories/business flows?	1	User stories often take this format—as a user, I want an X so that I can Y. Does your system have 30 of these flows? Is it likely to have much more in the future, or are changes mostly minor updates at this point? If it’s fewer than 30, don’t give your system the point here.
Does your application have 40+ user/stories/business flows?	2	We’re starting to enter the territory where we might want to consider DDD. Vaughn correctly highlights that we often do not identify complexity early enough and must pay for that decision later. Consider this your early warning that you are likely building a complex system.
Is the application likely to grow in complexity?	3	Some applications start simple, but there is a clear path to complexity. For example, if you were bootstrapping a startup, you might have something simple for the first few months. But as you attract funding, you know you will have to step up the complexity of the problem you’re solving.
The application will be around for a long time, and the changes you predict you need to make will not be simple.	4	There are very few systems that don’t undergo regular change. Understanding the complexity of the changes necessary is important to deciding whether DDD is right for you. Updating a holiday booking system to understand next year’s public holidays versus making a crypto exchange to support a new protocol are different classes of problems—the latter being worthy of the points for this category.
You don’t understand the domain because it is new, and as far as you are aware, no one has ever built a system like this before.	5	Modeling and defining a domain is DDD’s bread and butter.

Table 1.1 – DDD scorecard

If you score more than 7 points on the table, your application is a great candidate for DDD.

If you have scored less than 7, you may still benefit from some of the principles we will discuss in this book, but it might be that the time investment necessary to implement DDD properly is not worth it.

Committing to following the DDD principles is precisely that—a commitment. It cannot come from engineering; it needs to be a decision involving all project stakeholders. It requires time and effort to get the domain, language, and contexts correct and needs strong involvement from the domain experts. It also requires engineers to think one level higher than software and to think about behavior first.