>The main problem with DDD is that people stick to a shallow level of it, yet they label it as "doing DDD". Mostly, it's taking the code/organization you have right here right now - and labelling them somehow according to DDD's terminology .
This is the main problem with DDD because the literature is mostly a bunch of patterns and hand waving.
In this respect DDD suffers from the same problem as scrum or agile - the actual meat and potatoes of it is written about either in a way that is prone to encouraging cargo culting ("you must have a morning standup") or hand waving ("individuals and interactions!").
At this point I'm loath to give DDD any credit for anything at all because the ideas behind it existed before, it doesnt have a lot that is interesting to say on top of what it rebranded and it is written about very poorly in a way that practically encourages the kind of behavior OP described.
Tade0•5h ago
Regarding your last paragraph:
> DDD is the approach where we focus on OUR PRODUCT and UNDERSTANDING THE BUSINESS.
Guess I've been doing DDD all this time. Or: there are people who don't do that?
boxed•5h ago
What I've taken away from DDD is that consistent naming is important. Consistency > correctness even. But I think most programmers should already be pretty much on board on that one anyway.
johnh-hn•5h ago
That quote stood out to me too. I read the DDD book twice, about 5 years apart, and despite the experience I gained between the two readings, I felt the section describing ubiquitous language was the most valuable. I've seen genuine improvements in teams who adopt that, but I'm not so fussed about the rest of the book.
pydry•5h ago
The parts about how ubiquitous language and bounded contexts are correct and nonobvious but not novel - these concepts existed before under a myriad of other names.
DDD is pretty threadbare on opinions about how to manage your "ubiquitous language" or slice up your domain into "bounded contexts" after discovering that these are important concepts. That was already about 1/4 of my job before I'd ever even heard of DDD and then I had people throwing the book at me like it explained these things. It doesn't.
It works as a sales pitch to sell consulting I guess but is not a coherent framework for developing software.
smolder•5h ago
I worry that a lot of this conversation around web tech has become shibboleths to gatekeep a dwindling industry. You don't actually need to be an expert in angular or react or whatever unless you are churning out similar things in an assembly line style. The markers of a valuable hire are more basic: problem solving ability, ability to learn and adapt, communication skills, agreeableness...
pydry•5h ago
This is the main problem with DDD because the literature is mostly a bunch of patterns and hand waving.
In this respect DDD suffers from the same problem as scrum or agile - the actual meat and potatoes of it is written about either in a way that is prone to encouraging cargo culting ("you must have a morning standup") or hand waving ("individuals and interactions!").
At this point I'm loath to give DDD any credit for anything at all because the ideas behind it existed before, it doesnt have a lot that is interesting to say on top of what it rebranded and it is written about very poorly in a way that practically encourages the kind of behavior OP described.
Tade0•5h ago
> DDD is the approach where we focus on OUR PRODUCT and UNDERSTANDING THE BUSINESS.
Guess I've been doing DDD all this time. Or: there are people who don't do that?
boxed•5h ago
johnh-hn•5h ago
pydry•5h ago
DDD is pretty threadbare on opinions about how to manage your "ubiquitous language" or slice up your domain into "bounded contexts" after discovering that these are important concepts. That was already about 1/4 of my job before I'd ever even heard of DDD and then I had people throwing the book at me like it explained these things. It doesn't.
It works as a sales pitch to sell consulting I guess but is not a coherent framework for developing software.