[kingdomcome50]

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.

[stevebmark]

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".

[kingdomcome50]

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.