I worked on a number of software projects with Eric and got a lot out of his book before that. I'm sure you have good reasons for disliking DDD and I bet Eric would probably agree about most of them. This is what happens when ideas spread broadly. They end up getting applied in ways the originator never intended. (Jung reportedly said "thank god i'm not a jungian")

Eric's a fine writer and one of the smartest and most interesting people I've met. Nothing "snapped in his mind" and I can tell you for certain that he never tried to "force every idea into a class hierarchy" (quite the contrary! - he's very much a programming pluralist and spent a few years working in Clojure for that very reason). Nor would he ever do something as crude as trying to force a model (any model) onto software development as a whole. He's far too inquisitive and flexible a thinker.

By the way, Eric's way of programming and of thinking about programming was formed in the Smalltalk world, well before Java existed. Like a lot of the Smalltalk diaspora who ended up working in Java (and experiencing it as a kind of exile from the powerful and flexible Smalltalk environments they were used to), he thought deeply about what the differences were and how the Smalltalk design culture could be (partly) recovered and reshaped for these other technologies. A lot of creative work came out of that, not just DDD (e.g. Ward Cunningham's work, which led to Wikipedia).

I read the whole book, and I think my gripes are with Eric’s core thesis. Modeling your software around your core business concepts is a poison in most cases. If you hard code product names, stakeholder names, and specific business processes into your core software, you’ve locked your business into a bad place. The reality is businesses domains shift regularly, especially in new and evolving companies. Instead, software should focus on business agnostic functional layers. The business domain, as much as possible, should live in configuration and data. Even for the core data models you choose, they should be flexible and business agnostic to support future types of business operation. A good test of the poison is how easy it is to add a new product/service line/workflow/stakeholder/onboard a new customer. DDD creates bespoke work and pain around these business needs.

There are probably a minority of times where you want to lock in your business concepts to your core model and service layer, like in a stagnated business that isn’t changing, or something that’s a universal domain model in that industry. The rest of the time business domains should be configured at a higher level. The linked article makes a good argument about the flexibility of spreadsheets.

The issue with DDD is not in the philosophical concept. In that he is spot on. Things are in hierarchies, everything is described by a combination of two or more patterns that are more fundamental than those below.

The problem is always in people thinking it is an easy magic solution. DDD is not easy. If it were it wouldn’t do anything.

It is in fact very challenging to come up with an ubiquitous language, and to have it evolve as our own understanding evolves.

Organizations looking to use it to make things easier, are doomed to fail. What it can help with is making things good and right and even beautiful in how a problem is solved.

I'd like to complement that. Defining/Discovering the vocabulary for the Ubiquitous Language along with Bounded Contexts (Strategic Design) is where most benefits come from. And is, as said and I agree, the most difficult part - there are no recipes, shortcuts or tools to do that for you.

It doesn't help that there is a bunch of frameworks, libraries, articles with "DDD" on their name, mindlessly gluing together patterns and segregating them into layers (Building Blocks). What I see happening the most is people using them and complaining. Which they should.

Of the two parts that compose DDD, "Strategic Design" and "Building Blocks", only one is essential: Strategic Design. But people usually just talk about the "Building Blocks" (a.k.a Anemic Models), as it seems to be the case of "stevebmark" comment. I agree with him that just having Anemic Models, following blindly the Building Blocks part of DDD as rule, is bad. I just think that calling it DDD is a mistake. DDD is the Strategic Design, you don't even need the code for it to work or produce value.

> The book is one of the most poorly written technical books out there.

This explains the disconnect: it’s not a technical book. The part about patterns is garbage, as is anything which espouses object oriented Java circa 2004 (looking at you, Uncle Bob and Martin Fowler).

As a business book, parts 1 and 3 stand up rather well almost 20 years later. The patterns part (2) wasn’t even good advice when it was written, though.

One of these days perhaps I'll write a meta-pattern on how the software development industry goes through cycles. Every 10 years or so we discard techniques that only gave a 1-2% improvement instead of solving all the problems. We get distracted by a new thing will fix all that. We can't just add to our toolbox, though. First we have to have the ritual sacrifice of blaming all the failures of the previous 10 years on the old techniques, because they didn't solve all the problems.

Oh wait, it's already been written, by Fred Brooks no less. It's called No Silver Bullet.

The following is not an endorsement of DDD.

There are many glaring issues with the ideas presented in that linked "take down" of DDD.

I can forgive the early strawman comparing "spreadsheets" to bespoke software solutions. As if they cover exactly equal problem/solution spaces. Fine. I'll play along...

I can even forgive failing to understand that DDD is a design methodology, not an architecture; That DDD in no way prescribes or enforces any particular code organizational or deployment strategy. Easy to get wrong I suppose, and doesn't necessarily invalidate what could become a coherent argument...

But the author then has to go on and give examples of just how little they understand the topic at hand!

The first points to database software as "an example of good architectural design where their purpose of storing data is not confused with the domain the database will be used for". Oh the irony! Of course that's the case! The domain of database software is... (drumroll) persisting data! What would you expect to see if you opened the source code for an RDBMS? Code for blasting out marketing emails? I could go a step further and opine that it isn't possible to know whether any piece of software follows DDD without actually seeing the design/code base... but I digress. This point is not forgivable. It's a clear and obvious misunderstanding of DDD and how it is applied to systems.

The next examples they give are of applications they worked on! In both cases the author completely misses the fact that the software they "fixed" by decoupling it from the "domain" are simply examples where they followed DDD to create a "better" system. That's right! If the goal of your software is to create a generic "data integration application" or "workflow engine", then yes, coupling your design to "healthcare" is a mistake. Both are examples where the author is confused about what domain their software is servicing, and how aligning the software design to the correct domain was a major improvement. Hmm... sounds like DDD to me :)

I think there are valid criticisms of DDD, but the article linked is quite poor at articulating them.

This confirms my suspicion that "domain" has no definition. If "storing data" is a domain than anything can be a domain, and the word is meaningless.

There are logical groupings of nouns and functionality into services / modules / orthogonal parts of the software. Aggregate root is one useful term here, domain is not.

And for me it further reinforces the point of the article: design functional horizontal layers, not ones locked into your business "domains".

Come on now... You know perfectly well that "storing data" means something different to database software than some shitty LoB app. Let's not be so imprecise as to give off a disingenuous impression. The article makes almost no argument against DDD, and in fact could be a case study supporting the opposite conclusion! The author confuses architecture with design in every important way (similar to your "horizontal layers" comment).

DDD is not about how software is physically organized nor how it is deployed. You can have a traditional N-tier architecture AND follow DDD. The domain model is a logical model used to abstract the functional requirements of a system. It doesn't "lock" you in anymore than whatever else you have in place serving the same purpose. You cannot simply avoid your functional requirements. DDD is a methodology with the specific goal of drawing boundaries (answering "what" goes "where") in such a way to minimize the cost of change. If your resulting design is not doing so, you have simply failed to model your domain in a useful way.

In the author's case, maybe they really did need a generic "data integration" or "workflow engine" application. That's not an unreasonable assumption. And it follows that coupling those kinds of applications to the data/workflows contained therein would lead to all sorts of problems.

But surely he is not arguing that every application should be designed as a platform? It's considerably more difficult to design and maintain a "workflow engine" than "a single workflow", or a "data ingestion" application than to "just ingest the data". Most of the important bits in the above are already abstracted away from users.