Domain Driven Design - what is missing?

I had a chance to attend DDD Immersion https://domainlanguage.com/training/ddd-immersion/ - 4 days intensive course that covers the basics of Domain Driven Design (DDD).

It was held and fantastically organized by creator of DDD - Eric Evans and with the help of Paul Rayner. I am with DDD for almost 8 years now, so there was almost nothing new to me on the event. I wanted to somehow put a stamp on my dealing with this fascinating software methodology.

As far as content is concerned, most of this could be heard and read from books, courses as well as from Erik's video course https://elearn.domainlanguage.com/. So I can say that this was an introduction to a wide-ranging topic of DDD for beginners.

I have devoted much of my career to this topic and spent a lot of time learning, exchanging experiences, and applying the DDD principle in practice. I found this methodology to be a real jewel compared to the other pile of software trends. That is the reason I am writing this.

However, looking beyond the themes and content of this course something valuable emerged to me. I realized that we are missing something big in the world of DDD. And it is not SOMEthing - it is MANYthings.

First of all, applying DDD directly after reading a book and after initial introduction to the topic is possible only from the theoretical point of view. Most of examples are related to some kind of cargo shipping domain (like in Eric Evans red book) or product orders or similar applications - mostly chosen by developers.

Practice is completely different kind of beast. When we dive into real problems trying to hold the DDD principle, all the theories too often disappear, scatter and transform into what we knew from the past (usually CRUD). I very much respect other related areas like Event Sourcing and CQRS, but with them situation is slightly different because they are more technical.

Real world business problems, DDD is trying to solve are insanely dynamic and unpredictable. I don't want to go deeper into disapproval by management and the lack of basic design skills by the developers because it is omnipresent. As well as lack of communication between business people and developers.

The real trouble lies in trying to directly apply some very simple DDD patterns like bounded context and aggregates and solve complex problems with very limited tools like programming language. We know that ratio between well understandable spoken requirements and good implementation is somewhere around 1:100 - that is to say one line of requirement represents 100 lines of code. Even this perfect ratio is huge, although rarely achievable. We can see how our software tools and our ability to express business models with the help of programming language is limited by many factors - from knowledge, experience, talent, communication, tools, budget, time ... And we should find better way to do this.

For me, DDD represents unique software methodology with mission to accomplish one of the main goals of commercial software - and that is design based on business model. DDD understood in such a way is the nucleus and source of incredible energy that can be found at the root of many successful projects - without mentioning this at all. DDD just made it explicit and created conceptual framework around this source.

If DDD is such a powerful methodology, then we should use it cautiously and treat it as a valuable resource and as excellent theoretical basis. We need to build products and projects on top od DDD. We need to look what is core value of DDD and give it new life in our projects.

Something similar like relation between Git and Github. When Linux Torvalds created Git, it was just CLI tool that simplifies work for Linux kernel team. But when people created Github, they embedded core Git values into their product. So Git continues to live it's life but through metamorphosis. Btw just ask new developers to show you how to use Git through CLI - I doubt they will know. But clicking on a fancy Github web UI is completely different thing. But yet, they will still be using Git.

Back to MANYthings that are missing. We need to stop to directly follow theory and start to build environment in which DDD is possible. We need to build job boards, communication platforms, meetups, companies... We need new way of thinking that goes beyond coding and traditional software practice. We need to teach our teems not to type but to solve business problems .We need design, system theory, human resources, innovation, passion... We need third eye and the ability to indirectly observe DDD.

I think DDD has potential to make significant impact in the future, depending how it will be used and understand.