I only read the first third of the DDD book, the conceptual parts, which I thought were excellent, especially concepts like ubiquitous vocabulary and domain boundaries, which put a name to practices we’d already discovered.
But the underlying problem is that engineers are learning the domain as they write the code. This leads them to make invalid assumptions, which can go very deep, and make it extremely difficult to factor out later. If you build a feature based on bad assumptions, it can be really hard to remove or refactor it years later.
As it happens, I have written about 10 billing platforms in my life. If I was to build a new one today, I know exactly how to do it, and it will be super fast, efficient, and cover all the edge cases you can think of (please hire me :). My code structure would look nothing remotely like that written by someone doing this for the first time. They will make a bunch of fundamental mistakes, and most of those mistakes will be conceptual, because how can they know?. The problems range from accounting principles, to the nature of time, to user behaviour, and much more.
And the problem is that they will make the mistakes not because they don’t know how to write software, but because they haven’t spent years coming to understand the nuances and constraints of the billing domain.
No amount of software engineering boilerplate can fix that. In fact, the problem is that software engineering is largely discussed as a homogenous activity, but actually there are a million domains, each of them with different constraints, and because there are a limited number of specialists, we are constantly reinventing the wheel. To use my example, anyone can build a billing system because it seems obvious. But mostly those systems are going to be pretty flakey when they encounter the real world. And this principle applies to just about any domain.