That's fair, but I will point out that that's a bit of a "no true scotsman" argument, if it's meant as an argument. Regardless, I'm not really saying anything

That's fair, but I will point out that that's a bit of a "no true scotsman" argument, if it's meant as an argument. Regardless, I'm not really saying anything about DDD; just my experience of organizations saying they're using it. They may indeed be misusing it. They probably are, in fact; my whole point is that the orgs I've encountered that have figured out how to write software successfully don't say they use DDD (even if implicitly they do based on someone's definition of what DDD is), and the orgs I've encountered that say they use DDD to write software then execute very, very poorly, if at all, to the point I don't want to work for orgs that say they use DDD. I believe the cause of that experience to be that the orgs that have cultures that prioritize the right things to where product and dev align very rarely look to adopt new processes that purport to solve problems they already have solved, and the orgs that have cultures that create obstacles look to processes as silver bullets to address them. It's very likely akin to your comment about design patterns; a well built implementation may exhibit some design patterns, even without the author knowing that's what they are. A badly built implementation may look like someone had their gof4 book at hand and was looking for any possible excuse to use a pattern (and they're all named according, FooFactory, BarSingleton, so you can go "yep, they're using design patterns alright"). The latter isn't a judgement on design patterns, but the former may not find very much use for designating what is working for them as design patterns. I.e., it's not necessarily about what is actually in use, but what is being said is in use. My experience is that orgs that say they use DDD = avoid.