I agree, but for a different reason. If you've got a team of programmers on a project without any understanding of what the client is doing you're bound to implement stuff ass-backwards from the clients perspective.
DDD is fine in enterprise, but the domain does need to be communicated to all involved parties. You can't just dump a codebase on someone and expect them to get to work, that only barely works for non-DDD codebases let alone DDD codebases.
When inheriting a purist DDD project written in C#, I came across several... interesting... charts, including this one:
https://jj09.net/wp-content/uploads/2018/12/ddd-diagram-exam...
A lot of members of my team couldn't figure out where things were "supposed" to go (or what most of the terms mean) after weeks of working on the code, so they just started slapping methods anywhere and worrying about it later.
Well... If the carpenter needs to Google how to use a hammer and nails while at the construction side, something went terribly wrong, didn't it?
A hammer is such a simple and obvious concept that it should not need to be googled. If anybody needs to do that anyway, you should not put the blame on the carpenter, but on the guy who "designed" the hammer.
On a related note, I still very much am convinced that Don Norman's Design of Everyday Things is a great read for anyone who designs APIs; types in this argument function both as affordances and force functions, which are the exact reason why a hammer is such an obvious tool.
That's not like a carpenter who can't use a hammer. It's like a carpenter who asks for a sketch of a project and instead receives a phone-book sized list of vague instructions that no one can agree on.
I imply that a dev who doesn't understand DDD in a enterprise environment, is unqualified for working with DDD in an enterprise environment.
As much as a carpenter is unqualified to be a carpenter if he doesn't know how to handle a hammer and nails.
And I appreciate all the downvotes coming in.
In most of my projects I have had to learn a lot of new stuff, it's a blessing if someone on the team knows how to use it already. However I have found that on most projects we've struggled to hire people with substantial experience with the tech stack and methodology that the customer had chosen.
We still wouldn't find an entire team that had experience with everything we needed even if we paid them ten fold the amount of every other company.
On the other hand I reckon every carpenter learns to use a hammer and nails in school.
So? You don't leave university and expect to be "done", right? You learn, learn, and learn - your whole software dev life. Even better, your whole life.
And no - nobody teaches you how to professionally handle a hammer in school. Now you are simplifying here. In school, they show you a hammer and nails. That's it. As much as they show you a compiler, a programming language and a basic architecture in university.
There are a ton of different hammers and nails out there, each with their own special attributes. You have an engineer's hammer, a tiling hammer, a rubber hammer, a roofing hammer, a splitting maul, a sledgehammer and so on... And I won't start talking about nails.
It's up to you to gain knowledge when to use what, and how to use it. That doesn't mean it's useless per se. Or overly complicated. It might just no "be your thing", which is fine.
FYI a carpenter in Norway needs 4 years of education to become a carpenter. 2 years in school and 2 years as an apprentice. If they don’t know how to use a bog standard hammer by that time they are not passing the final examination.
Here in Germany, it's basically the same: A carpenter goes to school and work in a dual system for 3 years, and can then put a master on top of it after several years of working experience. This takes another 2 - 4 years and a ton of money.
This is very narrow-minded. DDD as a broad concept is good and something I practice.
DDD in enterprise is a disastrous nightmare. When people on your team are wasting time Googling lingo to try to figure out what kind of object they need, where to put a file, or where a method should go, it's a huge red flag.
I was on a team that seemingly spent all its time trying to figure out what the hell DDD was prescribing, let alone trying to figure out how to do it.