Does Your Project Score a Total of 7 Points or Higher?

If your Project.. Points Supporting Thoughts
If your application is completely data-centric and trully 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 can trust your users to insert data directly into a table, update it, and sometimes delete it, you wouldn’t even need a user interface. That’s no realistic, but it’s conceptualy releveant. If you could even use a simple database development tool to create a solution, don’t wast 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 as if 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 fewer busines 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 as application using Ruby on Rails or Groovy and Grail 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 about 25 to 30 single business methods, not 25 to 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 effor. 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 in the “Supporting Thoughts” column 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 - that 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 ore 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 then? It’s probably no 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 criteria, so use DDD