In my experience, the biggest hurdles are getting the business and engineers to follow the process.
Model->Validate with scenarios->Code Probe
Repeat as needed.
DDD lends itself to serverless and event-driven architectures and this is also a struggle.
Context mapping is important. Focusing on behavior is important. Identifying language is important.
Learning about Event Storming is also important.
But DDD is overkill for a straight data maintenance system (CRUD). The goal is to reduce complexity. Not create it.
Oh and the hard part. In DDD, abstractions and relational databases are bad starting points. You may end up with relational data stores, but the bound context should drive that. More often than not, a document data store is cheaper and more efficient. Abstractions are bad because we often see similarities in multiple boundaries and have an urge to combine things. But that’s a path to monolithic spaghetti.
I’m a huge advocate for DDD and believe many architects are stuck in PaaS. I think it’s critical to unwind that thinking.
A good example is how much greater would Salesforce be if they’d used DDD principles to design it? Clear boundaries. Clear modularization. As it is, it’s a tangled mess of monolithic code.