Domain-driven development

freestocks

A central difficulty in software development involves enabling everyone to understand and use the business domain concepts and language needed to build the software. Meanwhile, no-code automation avoids this problem completely.

Euro-English and domain language

Imagine building software with an international team that has evolved its own dialect of Euro-English that outsiders can’t understand. In theory, you could constrain the software to use a standard English instead by adopting an English dictionary. In a more extreme version of this thought experiment, coders might even use a programming language that only uses English words in code.

Imagine a software development environment that checked naming against a set of word lists. This would introduce a higher level of naming things, according to which dictionaries you choose. For a base English dictionary, you might choose a comprehensive dictionary or the deliberately reduced Basic English. For the business domain, you might choose between commercial or open-source supply chain management dictionaries, or develop your own.

Meanwhile, a team of native English speakers wouldn’t have to develop their own English dialect. But they would still have the same kind of problem, because so software systems end up using so much jargon - the domain language. Any software development team, regardless of native languages, needs a way to align on the words they use. Because words matter.

Domain-driven design

Domain-Driven Design promotes using domain language directly in the software implementation, so that you don’t have to map the business domain to different concepts in the code. This greatly improves complex systems’ maintainability, especially in enterprise software development.

Domain-driven design deserves its popularity, but its benefits come at a cost. Precisely defining and encapsulating the business domain in software requires learning, discipline and additional effort. Developers will also need to maintain additional documentation, such as domain language glossaries.

Perhaps the most important part of domain-driven design involves learning its ubiquitous language - the domain language - from the subject-matter experts who use it as a matter of course. Learning to speak a new language requires a lot of effort, which goes some way towards explaining the famous difficulty of naming things.

Domain-driven development

No-code tools exist to allow subject-matter experts to automate their own decisions and processes. In the same way that a group of native English speakers naturally use standard language, subject-matter matter experts using no-code automation naturally use domain concepts, structures, and language.

No-code automation needs a better name because the absence of code doesn’t explain everything. In particular, no-code doesn’t have to mean non-technical, any more than spreadsheets shouldn’t support sophisticated formulas and functions. Meanwhile, focusing on the absence of code or technical limitations distracts us from a more important capability. No-code tools replace domain-driven design with inherently domain-driven development.