BEYOND TECHNICALITIES

Where did the “domain” in “domain-driven design” go? The technical patterns of DDD are great for manifesting the domain within your implementation, but that doesn’t necessarily make it “domain-driven.” Shouldn’t the domain (i.e., the “real-world problem”) you are trying to solve through software come from the real world, as opposed to the technical world?

Communication, as highlighted through strategic design and most importantly the ubiquitous language introduced by Eric Evans, has always been the key to unlocking DDD. But how do we ensure that the real stakeholders in an organization or project drive the process?

I believe the answer lies in defining value. What if you ask yourself and your team: Are we producing value? Who would be able to answer that question? It’s not a philosophical question; it’s crucial to remember that we are paid monthly to provide a service. Whether the one paying us is an organization or an external customer, the vision, purpose, and most importantly the accountability for what you are working on originate there. As a result, the definition of value must originate there too. This makes them the true stakeholders. Therefore, domain-driven must mean that the software project is driven by a vision and a purpose defined by those who are ultimately accountable for it.

For a software project to be domain-driven, there must be clear communication through all roles—from the true stakeholders through product owners, project managers, UX/UI designers, software architects, developers, quality assurance, customer care, and so on. If not, how can anyone in these roles know whether they are producing value or not? And if you don’t know if you are producing value, it’s impossible to claim that you understand the domain. It is not enough to just monitor end-user feedback. If we cannot determine whether that feedback aligns with our overall vision and purpose, we cannot assess its value.

For the word “domain” to be part of DDD, we need a systematic communication framework that allows all stakeholders to be part of the same conversation (at the level they can contribute), using the same ubiquitous language, and all being able to contribute their parts while always staying within the frames set by the true stakeholders.