> I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc.

I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models that don't match their personal preferences on the acceptable tradeoffs between complexity and correctness.

As DDD comes up sounding like too much work to implement too much complexity that brings too little value, they flag it as a concern.

What I believe is missing from this discussion is the scenario where DDD practices are not followed and consequently teams are forced to iterate and reimplements projects or parts of it just to fit requirements that emerged because some aspects of the domain model weren't looked into. Design by accretion is largely accepted, as is technical debt, but they do have a cost.