Is DDD Overrated? | Domain-Driven Design

Last updated Apr 8th, 2022
DDD is one particular approach to software design. While highly influential and transformational for developers new to software design, I believe there exists a time to abandon the DDD ceremony to develop your own style. But first: mastery.

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


Discussion

Liked this? Sing it loud and proud 👨‍🎤.



Stay in touch!



About the author

Khalil Stemmler,
Software Essentialist ⚡

I'm Khalil. I turn code-first developers into confident crafters without having to buy, read & digest hundreds of complex programming books. Using Software Essentialism, my philosophy of software design, I coach developers through boredom, impostor syndrome, and a lack of direction to master software design and architecture. Mastery though, is not the end goal. It is merely a step towards your Inward Pull.



View more in Domain-Driven Design



You may also enjoy...

A few more related articles

Make Illegal States Unrepresentable! - Domain-Driven Design w/ TypeScript
By using TypeScript's static type system, not only can we enforce (typically challenging things like) business rules and error sta...
How to Handle Updates on Aggregates - Domain-Driven Design w/ TypeScript
In this article, you'll learn approaches for handling aggregates on Aggregates in Domain-Driven Design.
Decoupling Logic with Domain Events [Guide] - Domain-Driven Design w/ TypeScript
In this article, we'll walk through the process of using Domain Events to clean up how we decouple complex domain logic across the...
Does DDD Belong on the Frontend? - Domain-Driven Design w/ TypeScript
Should we utilize Domain-Driven Design principles and patterns in front-end applications? How far does domain modeling reach from ...