Having been in the DDD community for 15 years or so, it鈥檚 just...ridiculous how much time, energy, hell there鈥檚 entire books dedicated to the bike shedding here. It鈥檚 quite well documented
1
And I didn鈥檛 say that DDD was bad. The structural patterns, as the original author has said later, should have been *at most* an appendix or footnote in the book
1
1
If not omitted entirely. I tell folks to skip that entire section, it鈥檚 the least important part
1
1
I tend to agree with that except for aggregates. It usually takes time to get the idea, but in my experience is one of the keys to a good design.
But again, I鈥檓 not sure I follow when you attribute the bike shedding to DDD. Same can be said about REST, no?
1
1
1
Like: People have spent countless hours debating or trying to shove a procedure call into a resource-based model, while totally ignoring the strategic part of REST which is HATEOAS and actually delivers value (decoupling API clients and providers). (1/2)
1
Now, has REST done more harm than good? I don鈥檛 think so. People who believe they鈥檙e geniuses and grasp any idea just 20 minutes after hearing about it would do even more harm if they did so with SOAP. I鈥檇 attribute this to people, not ideas.
1
that's not an accurate comparison, as i referred to bike shedding the DDD *structural patterns*.
a better comparison would be if folks talking about REST spent 99% of the discussion around the Cacheable constraint
2
Well I don鈥檛 think aggregates are as trivial compared to DDD as Cacheable constraint is to REST. Comparing aggregates to resources or bounded contexts to HATEOAS seems pretty reasonable to me.
I鈥檇 blame myself for missing the point, not the more trivial parts of the whole idea.
1
I think a good analogy would be a discussion about when to use PUT vs POST vs PATCH
Mar 19, 2021 路 6:51 PM UTC
2
2



