When we shouldn't use Domain-Driven Design approach?

Question

I've been reading about DDD that I faced with this paragraph

For data centric operations you would probably be better off using something like an Active Record pattern, or even a DAL over stored procedures. You may find some benefits in some of the more cursory aspects of DDD, and perhaps using some of the terminology, but trying to make DDD fit here will not be a pleasant experience.

as well as this one:

Probably 95% of all software applications fall into the “not so good for using DDD” categories. Most are fundamentally Data Centric – most websites are, most desktop applications are … fundamentally most data updating and reporting applications are data centric.

So,what do you think? Do you accept this opinion? According to these paragraphs we couldn't use DDD for a wide rang of IT projects,could we?

Answer 1

Take those numbers simply as some values based on the author experience (Evans' book was published more than 13 years ago, things have changed since then).

First of all, the thing that (sadly) few devs understand is that DDD is all about a mindset, a way of looking at things. That's it. So you can use DDD in every project, because we still need to understand the domain first, regardless of its implemention. If it turns out the domain is just a bunch of data structures, then you don't need to complicate your life. Especially if you are building a 'dumb' app i.e a UI for the database.

But if you're building an app which needs to understand business semantics (concepts and behaviour) in order to automate things, then it's a different story and all those DDD notions will help you build a more maintainable app.

So it very much depends on your app, and even in that app things can vary a lot. You should first understand the app's purpose, then the domain it tries to represent (if that's the case) and come up with a solution for each use case. In one app, you can have a lot of CRUD stuff and you can be very efficient leaving out many abstractions and you can have a couple of important concepts and use cases that will require a much better understanding and design. It also matters how much you think that the app will change over time. If there are signs it's something that will evolve over time,it might be better to abstract things a bit, but only from a design point of view. The implementation can still be CRUDy at this point.

If you treat a methodology as a group of mindset and concepts, you can use it everywhere because something like DDD is not a 'how to' coding recipe. While it has some specific tools, you, the app designer should decide if they are good for your app.

Simply put, you have to use DDD in order to decide if (the whole) DDD is usable for some parts of your app. But once again, DDD means the strategic approach, the mindset.

It's simply wrong to decide on a solution from the beginning for the whole app. Understand the problems the app tries to solve and use the proper solution for each problem. If in the end everything is just CRUD, then it's ok. It's equally ok if only some parts are implemented using DDD tactical tools, the point is to have the optimum solution for a problem.

In conclusion, learn and understand the DDD mindset (there's a a lot of explanations out there, focus on the design, not on the recipes as they are wrong), avoid considering it a coding recipe and just use it in order to determine the best approach for the app's needs.