When should you use DDD?

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.