As we already know, Domain Driven Design is about Tacking the complexity in the Heart of Software.
Some important questions about that.
• Is there, not complex software?
• If they exist, should we use DDD in these cases?
Vaugh Vernon in his book, Implementing Domain-Driven Design, presented a Scorecard to help us to identify, the level of complexity of an application and, doing that, determine if it worth or not, applying DDD.
The idea of this scorecard is, after responding some questions, if your punctuation is equals or higher than seven you should consider using DDD if not, you should not consider using DDD.
Knowing that, we can use the table below, created by Vaugh Vernon, as a reference.
Read each description, described in the column “If your project…” andsum the value inside the column “Points” to discover if you need or not DDD to the project you are evaluating.
| If your project… | Points | Supporting Thoughts |
| If your application is completely data-centric and truly qualifies for a pure CRUD solution, where every operation is basically a simple database query to Create, Read, Update, or Delete, you don’t need DDD. Your team just needs to put a pretty face on a database table editor. In other words, if you could trust your users to just insert data directly into a table, update it, and sometimes delete it, you wouldn’t even need a user interface. That’s not realistic, but conceptually relevant. If you could even use a simple database development tool to create a solution, don’t waste your company’s time and money on DDD. | 0 | This seems like a no-brainer, but it’s not usually that easy to determine simple versus complex. It’s not like every application that isn’t pure CRUD deserves the time and effort of using DDD. So maybe we could come up with other metrics to help us draw a line between what is complex and what is not… |
| If your system requires just 30 or less business operations, it’s probably pretty simple. 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. If you could quickly and easily develop such an application using Ruby on Rails or Groovy and Grails and not feel the pain of lacking power and control over complexity and change, your system probably doesn’t need to use DDD. | 1 | To be clear, I am talking 25-30 single business methods, not 25-30 whole service interfaces, each with multiple methods. The latter might be complex. |
| So let’s say that somewhere in the range of 30 to 40 user stories or use case flows could be creeping toward complexity. Your system might be getting into DDD territory. | 2 | Caveat Emptor: Very often complexity is not recognized soon enough. We software developers are really, really good at underestimating complexity and level of effort. Just because we might want to code up a Rails or Grails application doesn’t mean we should. In the long run those could hurt more than help. |
| 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, but there is a step under Supporting thoughts that may help uncover the true situation. Be careful here. If there is any hint at all that the application has even moderate complexity—here’s a good time to be paranoid—it may be sufficient indication that it will actually be more than moderately complex. Lean toward DDD. | 3 | 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. |
| The application’s features are going to change often over a number of years, and you can’t anticipate that the kinds of changes will be simple. | 4 | DDD can help you manage the complexity of refactoring your model over time. |
| You don’t understand the Domain because it’s new. As far as you and your team know, nobody has done this before. That most likely means it’s complex, or at least deserves due diligence with analytical scrutiny to determine the level of complexity. | 5 | 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, so use DDD. |
After reading the descriptions and sum the points for, each one that describes your project’s context, you can decide to use or not DDD.
This is a great tool to help us on those situations, keep this scorecard close to you and don’t forget to use it when necessary.
Thanks for reading, I hope you have enjoyed.
