The pros and cons of domain-driven design
The pros and cons of domain-driven design
When preparing business cases, developing ideas and implementing software solutions, software developers like to modernise without having to reinvent the wheel. A well-known technique for doing this is domain-driven design, or DDD. By using a common language (ubiquitous language), a design (or “domain model” is created. By defining themes, the subjects (entities) are described. This is done without reference to the solution itself (technology and software architecture).
Eric Evans is a pioneer within the field of domain-driven design. According to him “[e]very model represents some aspect of reality or an idea of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving a problem at hand and ignores extraneous detail in domain-driven design.”
The model provides documentation in the language of the knowledge worker in the problem domain. This means that the model is written in a language without technical solutions and is understandable for the knowledge worker and other stakeholders. If several different terms are used for the same subject, the most appropriate term is chosen.
Advantages of domain-driven design
Eric Evans explained much more about DDD in his book Domain-Driven Design: Tackling Complexity in the Heart of Software. Here we’ve listed some of the biggest advantages of DDD.
1. The ubiquitous language – where everyone involved in the project uses the same language, from development teams to domain experts – ensures that the end product makes sense to the end user. Furthermore, the terminology and definitions that are used in the application are in line with activities and terminologies in the “real world”. Because of that, users will understand the ‘how to’ of the application more quickly and will be less likely to get frustrated while using the app.
2. For developers it is much easier to communicate with the business team, as they are familiar with the terms too. It follows that there is less chance of miscommunication or misunderstandings between the development team and the domain experts.
3. The business flows more easily. New team members can easily ‘hop in’ if others move on to another project. They’ll also understand the language and will benefit from valuable project-specific knowledge already gleaned.
4. Using DDD leads to cleaner, more reliable code. Best practices can be used repeatedly, as well as design patterns. Future projects will run more smoothly and easily.
5. Do you need to deal with implementing required changes to the application? As everybody has the same understanding of the business domain, it is easier to deal with them.
6. If you want to be informed of required implementation, it is easier to track this. This is a consequence of the common set of terminology and smoother communication within the area of app development.
7. The UX/UI software is likely to be popular with users. The most important thing is to create an application that is easy to use for the users and offers them the functions they need. DDD helps in finding a balance between what the domain needs on one hand and what the domain experts recommend on the other. As a result, the application suits the users’ needs and expectations.
Disadvantages of domain-driven design
As explained above, domain-driven design has many advantages. However, DDD is not always a suitable solution. Take these disadvantages into account:
1. DDD requires your organisation to have at least one domain expert on the team. This person needs to have a deep understanding of the domain where the software is meant to be applied. The reason for needing this in-house knowledge is that you want to make sure that you put the right features into the domain context.
2. As long as developers are not domain experts, they and the business team need to put effort into understanding the domain thoroughly. This could be time-consuming. However, as soon as they develop the domain knowledge, this disadvantage is not relevant anymore.
3. If you work with relatively simple domains, DDD could create more work than necessary. Take, for example, a job application. You need to enter personal data, your CV, maybe some references, and a cover letter. That’s it. DDD is not necessary in such a case as the complexity of the task is low.
4. At the opposite end of the spectrum, if you work on highly technical projects it is not recommendable to work with DDD either. In such a case it is hard to create a ubiquitous language that can be understood by everyone involved in the project.
