Domain Driven Design makes so much sense. But, in my opinion, it's generally just an excuse for people to show how smart they are. They often don't talk to any other department, they'll come up with excuses for this and refuse to admit that they're not doing DDD. They'll claim they're doing "tactical DDD" or some other name. These same people will force everything to be immutable even tho it's clear under DDD that entities are in their nature mutable. It's often a collection of doing things that aren't what they're meant to be.
If you're actually talking to other departments and have a very tricky domain I fully believe that DDD can solve some major problems. If not, I think you just want to show off how smart you are. And if you want to show me how smart you are do it by solving problems for people. Especially the problems that others can't solve.
DDD is simply a common sense. Every sane project models domain in domain terms and has layers. There is no need in ceremonies around file structure and method names.
It's not almost it is exactly the definition. The key thing about DDD is ubiquitous language, which is everyone using the same language. And learning things from the domain experts who are in other departments. If you're not talking to other departments you can't be using the same language as them. Nor can you learn from the domain experts. Nor even ensure that the domain flow maps the same as the company. DDD and BDD are fundamentally about talking to people. But that's the hard part so people skip it.
If you're actually talking to other departments and have a very tricky domain I fully believe that DDD can solve some major problems. If not, I think you just want to show off how smart you are. And if you want to show me how smart you are do it by solving problems for people. Especially the problems that others can't solve.