Having been in the DDD community for 15 years or so, it’s just...ridiculous how much time, energy, hell there’s entire books dedicated to the bike shedding here. It’s quite well documented

And I didn’t 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

If not omitted entirely. I tell folks to skip that entire section, it’s the least important part

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’m not sure I follow when you attribute the bike shedding to DDD. Same can be said about REST, no?

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)

Now, has REST done more harm than good? I don’t think so. People who believe they’re geniuses and grasp any idea just 20 minutes after hearing about it would do even more harm if they did so with SOAP. I’d attribute this to people, not ideas.

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

Well I don’t 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’d blame myself for missing the point, not the more trivial parts of the whole idea.

Yeah I dunno whatever the piece in REST that Fielding would have rather never been in the dissertation Like Evans has said about the structural patterns should have never been in the book (or at most an appendix)

I think a good analogy would be a discussion about when to use PUT vs POST vs PATCH