I realize that DDD (Domain-Driven Design) is a subject that is increasingly sought after by developers. Even so, its meaning can be quite confusing for some people. If you have never heard, or have heard but want to have another perspective, or are still unsure about the points below, this article is for you.
- What is DDD?
- DDD is an architecture?
- DDD is the ideal model to work with?
What is DDD?
DDD is a development philosophy disclosed by Eric Evans since 2003. “Disclosed” because not everything was his creation. He realized that a set of good development practices, teamwork and business strategies can contribute to a complex project to be successful.
Known for his book "Domain-Driven Design - Attacking Complexities at the Heart of Software", Evans presents such a big paradigm shift on how to understand and solve complex problems, that he inspired several other great books on the subject.
DDD is an architecture?
We have traditionally learned a software analysis and development model similar to this: business analysts, in conjunction with business experts and / or key users, will carry out a functional survey, and prepare an extensive functional specification document. Perhaps here we have the participation of a database specialist to perform the MER, and perhaps some more documents and diagrams. This specification will be sent to the architect, or technical leaders / managers, who will design the project architecture, in order to meet the specified requirements. Other concepts well seen in the market, but which were not expressly requested, can be included in the architecture, such as a high level of abstraction and code reuse, a data access layer that allows the exchange of the DBMS without impacting the project, various Patterns and etc. . Then, the developers will get their hands dirty and implement the requirements. The developed project will be made available to key users, who will validate and approve it, as shown below:
And everything works according to specification, right? 🙂
Well, if you were comfortable with that description, and are confident that this model will work, perhaps the rest of the article will be a bit of a nuisance.
I say this because in most cases this model does not work. Among the possible reasons, I can quote:
- The view of the business analyst may not be technical enough to understand the risks, deadlines and impacts of the solution;
- Understanding a business is growing. The first version of a functional specification is hardly the one that adequately solves the problem;
- The architect, or technical officer, will design the solution according to the specification, which may change throughout the project. That is, the architecture proposed at the beginning may not be the most suitable at the end;
- The architect or technical manager, if he does not have a close contact with the development team, can make architectural or implementation decisions that are not compatible with the team, either by skills techniques or even by development style;
- If the architect has a limited view of the problem to be solved, the developers have double: in addition to the functional specification that tends to lag, they are working on an imposed architecture that does not necessarily solve the business problem. It can solve problems that don't exist, such as changing a database that may never happen, and not being flexible enough for the application to grow, for example;
- The developers will do their best to meet the deadline and requirements within the imposed architecture. However, when the project was made available to users, perhaps months after the business analysis, users understood that this was not quite what they wanted.
The changes will be necessary to meet the current needs of users, not those of months ago. But developers may find it difficult to implement changes within an enforced standard. This creates accidental technical complexity. The code is often more complex than it should be because it needs to follow certain standards defined at the beginning. As the system grows, the accidental technical complexity becomes greater than the business complexity itself.
Domain complexity vs. software complexity
This is precisely why comparisons of software development with civil or electronic engineering tend to fail: The project grows. The understanding of the business grows. Needs change. And sometimes, even when the need remains the same, the notion of what the appropriate solution will be changes. Developing software in a way that does not allow for structural changes during development usually leads to poor quality projects and many overtime hours.
And what does DDD have to do with it?
DDD is a philosophy focused on the business domain. Understanding the business domain is a growing process, which requires the cooperation and communication of the team as a whole. Instead of the traditional model, in which communication occurs in just a few stages of the project, we have a continuous and collaborative communication flow, through a single language.
Analysis and development flow with ubiquitous language
The code reflects the domain, in the same language as business experts and users. Strictly technical terms are replaced by terms that the user understands. Perhaps some diagrams can serve as support, but instead of extensive and detailed documents, we have a rich, clear and cohesive code.
The development team as a whole becomes responsible for the project's architecture. The role of the architect may even continue to exist, but in a much more collaborative position and closer to the day to day development.
The implementation of the solution is emerging. It starts simple, and grows with understanding the domain, not in separate steps. It may be that at some point, it is noticed that the architecture does not meet more. A key concept that impacts on the clarity of the domain (code) can be perceived, generating the need for partial refactoring. And it's okay if that happens.
Time is not invested in patterns and abstractions that are not necessary. The team's energy, technical or not, is directed towards a single objective: to solve the domain problem, in a way that the code reflects the domain.
In summary, even though DDD is not an architectural standard, it affects how architectural decisions are made, and the architect's own role in the team.
It sounds great, doesn't it? This brings us to the next question:
DDD is the ideal model to work with?
The answer is ... It depends! First, DDD is a way of dealing with complex domains. If the domain in question is simple, you will be more efficient using simpler designs. But even if the domain is complex, other factors must be considered:
- Company culture: a company that is used to ITIL or similar, with well-defined roles and segregated teams, will have difficulties in breaking these barriers to a collaborative model. It may be that, as far as possible, things are going well that way, so there is no need to change. But if the current model of work is impacting deliveries, generating wear and tear, outdated documentation and low quality code, among other effects, managers may feel the need for change. If so, it may be worth talking about DDD, which does not guarantee that managers are comfortable with the proposed changes. In other words, the people involved need to want and believe in this change, to the point of communicating and collaborating directly with the development of the software, and not just with the specification and deadlines;
- Developer engagement: For the code to reflect the domain, a number of development practices are recommended. There are many ways to solve the same problem, and many ways are accepted, provided that when analyzing the application, it is possible to understand the main domain, its rules and peculiarities, which auxiliary domains, how they relate, etc. It is not enough that only half of the developers are engaged in coding reflecting the domain, everyone must assume this responsibility.
DDD is aimed at complex domains, and depends on breaking down communication barriers between business specialists and technical specialists, in addition to the engagement of the technical team in programming so that the code reflects the domain. If one of these variables is negative, the DDD is probably not suitable for the scenario you are dealing with.
It is already clear that DDD is not an architecture, nor a silver bullet that will solve any problem that comes. But if your team identifies that the domain in question is complex, and is willing to program it in such a way that the domain representation is clear even to the business experts, and realizes that the client or company is interested in constantly collaborating with the understanding domain and solution validation, DDD may be a good development approach.
How to apply it, then?
There is no quick answer to that question, so in the article Distilling a domain with DDD. I will show an example of how to apply DDD principles in the domain and architecture distillation process of the solution. I hope that I have helped readers understand what DDD is, or at least, what DDD is not.
And the recommendation is to seek information directly from the source. If Evans' book is very dense (and it is), I recommend starting with a more didactic and practical one: “Patterns, Principles and Practices of Domain-Driven Design”, by Scott Millett and Nick Tune. It is a lighter and more direct reading, with examples of implementation in C#.