Does Domain Driven Design has a wrong audience?

I dare to think that Domain Driven Design (DDD) has a wrong audience. Wikipedia says that DDD is an approach to software DEVELOPMENT, but does this mean that is should be used by software DEVELOPERS ? Or maybe this definition is wrong ?

Software is about programming languages and whole infrastructure that goes with it - it is about frameworks, libraries, algorithms, tests, classes, methods, editors, IDE-s ... It's a craft that people are dedicated to. It is rarely seen as a means of business. That is why we have an expressions like coding. How is coding different from running, painting, digging, playing ? Not much. All of these crafts requires certain skill sets, grown for years and what is important - used in very generic ways. So you can run on different basis, play different music, paint using different techniques and code in different languages. You can do your craft.

Critical part is when you need to embed your skills into something that will greatly determine the way you work. When you realize that your craft is just a servant of something you do not know much about and you don't have control over it. This is exactly what happens to many developers trying to grasp DDD. In politically correct fashion, they read books and watch a few courses because DDD is marketed as software methodology and learning new things is a must for any modern developer. Next what they do is try to translate it into known language - that they use every day. And then, frustration is born. (happened to me also). Many of them have a repulsive, almost hostile attitude towards DDD after initial meeting.

When trying to learn and apply DDD all we have is our editor and our code. No domain expert, no ubiquitous language, no business model, no productive communication, no bounded context. We are trying to type something and quickly see results, because this is how craft is done. In very rare situations we are directly interested and motivated for the characteristics of what we implement. In most cases, it is not our concern. Our job is to spit code on the screen and make sure that is runs correctly. Very often, only project management tasks are our only guide and source of wisdom.

Those who care about job information and outcome are business people, domain experts, CEO-s, investors, managers ... They are directly interested to implement their ideas and to find common language with developers. They know the context, core and supporting domain, strategy, market ... It's simply not natural to ask for developers to know all of these things. They are not taught to think in such a way.

One of the most important reasons why DDD should be more interesting to business people is in ratio between requirements and implementation. In classic software practice, this ratio is very high - one spoken requirement needs many lines of code. DDD with concept of ubiquitous language represents kind of linguistic phenomenon. It is trying to to establish more direct communication between all involved parties in the project. This makes DDD very potent methodology and implementation ratio in some cases it rapidly decreased. Every business person likes to be understandable and that their ideas are quickly implemented. At the end, this saves money. DDD makes this more easier then any other known practice. But it is not something developers think about.

I think that initiative for applying DDD should come from business (people), because it can bring new value to their projects and ideas. In reality, initiative is coming from developers and DDD is often seen as some new and trendy fashion. We know that investing into new things is expensive.

Putting these two parties on the same table is challenging task. It is influenced by lots of things. We need better glue to connect people around DDD. Traditional projects in which domain experts and developers are connected just for the purpose of doing a job is not enough. I think teams gathered around DDD projects need to have stronger inner connections - political, sexual, ideological, environmental, financial, spiritual ...