Is DDD Overrated? | Domain-Driven Design

Is Domain-Driven Design (DDD) overrated?

In my opinion, you can only say DDD is overrated once you've achieved mastery over it. At this point, you can toss it aside. All the tactical patterns, techniques, approaches — you've already absorbed the wisdom. You're the boss. You don't need rules, cerimonies, other peoples' best practices. You set your own rules. Because you understand design, you know what's good, bad, too much design, too little, what the correct amount thereof is (see the Golden Mean) — you now have room to experiment and get creative.

If you're an experienced developer (perhaps like the author of this excellent post of the same title), you've likely witnessed the rise of use cases, responsibility-driven design, and have experience with various approaches to object-oriented and functional software.

For you, yes. DDD may very well be overrated.

But for everyone else — the junior developers, the fresh developers, the devs who don't know software design, the devs still struggling to learn where to put their business logic — DDD is a game-changer.

To quote Eric Elliot,

"99% of fresh CS grads don't know the basics of software design".

Since DDD is a very human approach to design, developers w/o software design experience who study it gain two things:

1. How to write code for humans
2. A shortcut to some of the most important design concepts

That being said, we should eventually leave DDD and look beyond it to fully understand software design, otherwise we treat DDD as a sort of dogma.

A developer will read the DDD material and think, "Well that's it. I've learned the secrets." When all they've learned is the rudiments of one angle on software design. - via Scott Bellware

Other great approaches exist as well, like Responsibility Driven Design... and if you look closely, you'll see a lot of similarities to DDD (look into Object Stereotypes and see how a Value Object or an Entity is essentially an Information Holder object stereotype).

What do these similarities tell us? That we're close to some ineffable truths or laws of design. Or at least a little further into our discovery of the mystery that is software design.

Summary

In summary,

• Every developer should learn DDD
• Every developer should then learn the truths of software design that make DDD effective
• Every developer should then abandon anything cerimonious about DDD and develop their own style based on their own experience