[latte]

The principles listed in the article look like general common-sense design principles. I can hardly imagine anyone designing a system without understanding the problem domain first - and likewise, the problem domain usually drives the underlying models (because what else can they be driven by)? I acknowledge that something the design process strays away from the original domain requirements (especially among the less experienced teams), but that usually feels wrong irrespective of the design philosophy. So the definition of DDD seems a bit tautological.

I would appreciate an explanation of what DDD is by counterexample - i.e. what are examples of non-domain driven design process? Especially, examples of successful or mostly successful projects - i.e. where the disconnect from the problem domain does not feel wrong from the start.

[HelloNurse]

Typical oldschool enterprise software that has database tables instead of a decently abstract model, pages instead of services, "it should happen very rarely" instead of invariants, "don't do that" instead of validation, lore instead of design, etc.

What's particularly contrary to DDD principles and common is mixing up different concerns without regard for model integrity (e.g. ad hoc incorrect caching of stale data for performance reasons, messing up all business logic).