Is DDD suited for all kinds of application?

Question

One common reaction that I see for a lot of questions asked here and other forums are like "You don't need to do DDD for that. Its a simple CRUD application, DDD is an over-engineering".

Well I am new to DDD and I feel there are a lot of elements in DDD that has universal appeal and can be used across the board, irrespective of the fact whether your application is complex enuf to mandate DDD. For example, layering of application, differnent artifacts that DDD recognises etc. May be start with the basics and admittedly anemic models and then work/refactor towards as much purity as one can get.

Does this approach sound good?
Or would you say that there is a fundamental choice in design of every application in terms of whether to go DDD way or not , kind of "all-or-none" choice?

UPDATE (to provide more context, in response to hugh's comment below)
  I am building a webapp around an existing RuleEngine kind of application, basically CRUD and some validations, invariants and then a process of deployment. The rule-authoring and semantic check is done by a standalone piece of code that i call as part of the CRUD and none of that semantic specific logic is there in my code. I am trying to use DDD for this application, but i see it might not be complicated enough to fit into the DDD paradigm. There is no ubiquitous language defined for the domain i.e the language is not specialized enough beyond naming the set of entities involved. I hear my domain expert speaking in terms of creating, editing, deleting entities.

Answer 1

DDD is not all-or-nothing. Also, many of the patterns described in DDD are not new and can be found all over the place. Eric Evans (the author of the DDD book) just assembled them, formalized them where needed, and set them in relation to each other. You are free to use what fits to your problem space.

What is often overlooked: DDD describes implementation patterns as well as analysis patterns. The analysis patterns may be overkill in many (if not most) applications, but the implementation patterns (i.e. Entities, Specifications, Services) can be of great use in less complex scenarios as well.

Answer 2

In short,

If it's just CRUD, I wouldn't bother.

On the other hand,

If it's got behavior, where the next state of something relies on the previous state, then DDD is something you probably want to consider.

Answer 3

DDD approach is based on two type of patterns: Strategics patterns and Tactical patterns. IMHO, be free to use tactical patterns in every case that you sure can be helpful. But using Strategic patterns can be overkill for some type of domains. If CRUD style thinking, does not have negative impact in modeling process, certainly you doesn't gonna need it.