Do we need DDD in our project?

Ahmed Ibrahim
2 min readAug 25, 2020

Does Your project qualify to use Domain-Driven-Design?

we can answer that question by answering the following questions created by “Vaughn Vernon”, each question we answer with yes will add points if we scored 7 or more points then we will need to use Domain-Driven Design.

Ready? Let’s Go.

1- does your application is completely data-centric and truly qualifies
for a pure CRUD solution, you don’t need DDD. In other words, if you can trust your users to insert data directly into a table, update it, and sometimes delete it? (0 point if yes).

2- does your system requires just 30 or fewer business operations?
This would mean that your application would have no more than 30 total user stories or use case flows, with each of those flows having only minimal business logic. (1 point if yes).

To be clear, we are talking about 25 to 30 single business methods, not 25 to 30 whole service interfaces, each with multiple methods

3- does your system have 30 to 40 user stories or use case flows? (3 points if yes)

4- Even if the application is not going to be complex now, will it
grow in complexity? You may not know this for sure until real
users start working with it? (3 points if yes)

Very often complexity is not recognized soon enough.

5-are The application’s features going to change often over a
number of years, and you can’t anticipate that the kinds of
changes will be simple? (4 points if yes)

Here it pays off to walk through the more complex
usage scenarios with domain experts and see where it
leads. Are domain experts . . .
1. . . . already asking for more complex features?
If so, it’s likely an indication that the application is
already or will soon become too complex to use a
CRUD approach.

2. . . . so bored with the features that they can hardly
bear discussing them? It’s probably not complex.

6- Are the domain you and your team working on is new, nobody has done this before? (5 points if yes)

You are going to need to work with domain experts and experiment with models to get it right. You certainly also scored on one or more of the previous criteria, so use DDD.

Conclusion:

We should not use DDD for all our projects, DDD is particularly suited to complex domains, where a lot of often-messy logic needs to be organized.

References:

Also, Check my My Journey in Learning Domain-Driven-Design

Part1(Intro To domain Driven Design)

Part2(Layers and Hexagonal Architecture)

part3(CQRS)

--

--