Understanding Domain Driven Design
by Juan Banda
Continuing my series of Spanish interviews for Agile Alliance, this time I had the great pleasure of talking with Miguel Viera, a developer, who together with his colleagues from Codesai provide consulting and technical mentoring in Spain.
Miguel is passionate about the technical side of Agility and his interest these days includes Domain Driven Design (DDD), a subject he decided to talk about in the interview.
He began by offering a definition of Domain Driven Design: For him, DDD is a set of principles and practices that help developers create software from a better interpretation of business terms, and this better interpretation of the domain helps to improve the processes that they have to follow when coding.
Miguel says that the main reason DDD exists is for the creation of a ubiquitous language that can be understood by the business and the developers. This ubiquitous language is a way of distilling all the metalanguage that people colloquially use to communicate.
The idea is that this ubiquitous language is not documented with written text, but rather is incorporated into the code itself. The result is that within the code, the names of variables, procedures, etc., will end up better reflecting developers’ understanding of the business domain and the problems the code is trying to solve.
Miguel also observed that many times there are words that are used correctly from a semantic perspective but do not reflect the meaning of the business. This phenomenon is known as “loss in translation”, which basically consists of using semantically correct terms which do not make much sense in the business domain. This “loss in translation” when reflected in the code makes it more obscure for those who read it and try to understand it, limiting its adaptability and extensibility in the future.
He commented that for this ubiquitous language to be created more effectively it is ideal for developers to interact directly with someone from the business, but this is often not feasible due to physical or company limitations. If these limitations are present, the presence of a Product Owner who fully understands the business can be a valid substitute.
According to Miguel, code that does not adequately reflect the problem domain will end up creating an extra complication for those who try to understand it, because in addition to understanding the code itself it will be necessary to decipher how the problem domain was worked on. That is, trying to translate the translation, which will end up causing additional complications.
Miguel pointed out that TDD is a practice that fits perfectly with DDD because it captures the ubiquitous language, which is then translated into tests and code that will make more sense within the context of the business. The entire domain language could, in most cases, be programmed in any programming language unless there are technical factors that bias the choice of a particular programming language or paradigm.
He assumes that DDD has not been used more among the development community due to a change in interpretation of what technical excellence is, since now the focus should not only be on the tools and technical practices but on the understanding of the domain. Thus, technical excellence has to do with understanding the business, proposing business solutions, and then implementing them. Raising and discussing solutions with business people is what ultimately makes development more iterative and incremental.
To close the interview, Miguel commented that a starting point for those who wish to enter DDD is to read Eric Evans’ book, with special emphasis on trying to understand the technical limitations that not fully understanding the domain of the problem will bring in the tactical part. His final reflection was that technical excellence for a developer consists of holistically understanding the product he is building.
Originally published at https://www.agilealliance.org on November 7, 2020.
