Is DDD suitable for all kinds of applications?

Question

One general reaction that I see on a lot of questions asked here and in other forums is: “You don’t need to do DDD for this. This is a simple CRUD application, DDD is over designing.”

Well, I'm new to DDD, and I feel that there are many elements in DDD that have universal appeal and can be used everywhere, regardless of whether your application is complex enuf for the DDD mandate. For example, application bundle, various artifacts that DDD recognizes, etc. It can start with the basics and admittedly anemic models, and then work / reorganize to as much purity as you can get.

Is this approach good? Or will you say that there is a fundamental choice in the design of each application in terms of whether to go in the DDD way or not, something like choosing "all or nothing"?

UPDATE (to provide more context, in response to hugh comment below)
I create a webapp around an existing RuleEngine application, mainly CRUD and some validations, invariants, and then the deployment process. Validation and semantic validation is done using a separate piece of code, which I call part of CRUD, and none of this semantic specific logic exists in my code. I am trying to use DDD for this application, but I see that it may not be complicated enough to fit into the DDD paradigm. There is no ubiquitous language in the domain, so the language is not specialized enough to name a set of entities involved. I hear my domain expert talking about creating, editing, deleting objects.

Answer 1

DDD is not all or nothing. In addition, many of the templates described in DDD are not new and can be found everywhere. Eric Evans (author of DDD) just assembled them, formalized them where necessary, and set them in relation to each other. You can use what suits your problem space.

Often ignored: DDD describes implementation patterns as well as analysis patterns. Analysis models can be excessive in many (if not most) applications, but implementation patterns (i.e. Entities, specifications, services) can be useful in less complex scenarios.

Answer 2

In short,

If it's just CRUD, I would not bother.

On the other hand,

If he has a behavior when the next state of something depends on the previous state, then DDD is something that you probably want to consider.