mathiasverraes's comments

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. Good abstractions make complexity manageable, bad ones create more complexity. And that's another problem: a domain might be quite straightforward but bad explanations, missing information, bad abstractions, etc can make it seem more complex.

Your colleagues need to remember that DDD is supposed to be applied pragmatically. If the structure causes more navigation work than needed, simplify it. If the problem could be solved with a simple CRUD system, do that. If most of the problem is CRUD, but there's one particularly complex bit that changes a lot and requires a lot of flexibility, isolate that part, so that the simple and complex parts can have a simple integration, don't leak into each other, and can evolve at their own speeds.

The definition is highly summarised, which (like many definitions) makes it only useful if you already understand the concept, and you need a way to remember it. Or the definition can be a framework for explaining it to others, which is how I use it in workshops.

A more real world story of DDD in practice is this blog post:

https://verraes.net/2021/09/design-and-reality/

These articles are pretty much impossible to disagree with, because they follow the same pattern.

Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take.

§1 Clickbait title

§2 Tool X is popular. I'm a fan. Tool X is useful.

§3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough.

§4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X.

§5 Conclusion: Not all things require Tool X.

(1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance.

It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer.

Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)

> The biggest flaw of DDD I've run into is there's no emphasis on when not to use it

Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.