DDD Is Overrated

You make some valid points, but “good ideas written by someone who should not communicate with humans” - a bit harsh don’t you think?

My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned:

1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture

2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it.

3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help.

4. You don't have to adopt Microservice combined with DDD.

5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful.

The Good:

1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind.

2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices.

3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design.

The Bad:

1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry.

2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler.

The Ugly:

1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream or Flux, unless you are using advanced languages like Scala and can parametrize them as TMonad

2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive.

3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.

You’re probably right, but it’s still better to spell it out in the title when a good percentage of readers will either be unfamiliar or think of something else.

I was literally introduced to that term with this article while I've been using ddd off and on for 20 years

Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality.

Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.

People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other."

I mean holy hell, did a markov chain write that?

Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it.

In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways.

It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English.

I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that.

In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority!

Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup.

Go work on harder problems, seriously

I came here expecting a critique of the DDD debugger :(