Domain-driven design

Domain-driven design (DDD from here on) is an approach for the development when it has complex needs. This concept is not new; it was created by Eric Evans in his book with the same title in 2004, but now it is mainstream as microservices are popular among developers and very common in huge projects.

This is happening as there is great compatibility between the microservices concepts (regarding the software architecture, piding every functionality into services) and DDD concepts (about the bounded contexts).

Before knowing where and how we can use DDD in our microservices project, it is necessary to understand what DDD is and how it works, so let me introduce you to the main concepts as a summary of this approach.

How domain-driven design works

Evans introduced some concepts that are necessary to understand to learn how domain-driven design works:

• Context:This is the setting in which a word or statement appears that determines its meaning.
• Domain: This is a sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software.
• Model:This is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
• Ubiquitous language:This is a language structured around the domain model and used by all team members to connect all the activities of the team with the software.

The software domain is not related to the technical terms, programming or computers in any way. In most projects, the most challenging part is to understand the business domain, so DDD suggests using a model domain; this is abstract, ordered, and selective knowledge reproduced in a diagram, code, or just words.

The model domain is like the roadmap to build projects with complex functionalities, and it is necessary to follow five steps to achieve it. These five steps need to be agreed on by the development team and the domain expert:

1. Brainstorming and refinement: There should be a communication channel between the development team and the domain expert. So, all the people in the project should be able to talk to everyone because they all need to know how the project should work.
2. Draft domain model: During the conversation, it is necessary to start drawing a draft of the domain model, so that it can be checked and corrected by the domain expert until they both agree.
3. Early class diagram:Using the draft, we can start building an early version of the class diagram.
4. Simple prototype: Using the draft of the early class diagram and domain model, it is possible to build a very simple prototype. Evans suggests avoiding things that are not related to the domain to ensure that the domain business was modeled properly. It can be a very simple program as a trace.
5. Prototype feedback: The domain expert interacts with the prototype in order to check whether all the needs are met and then the entire team will improve the model domain and the prototype.

This process will have all the iterations needed until the domain model is correct:

The model, code, and design must evolve and grow together.They cannot be unsynchronized at all. If a concept is updated on the model, it should also be updated on the code and on the design automatically, and the same goes for the rest.

A model is an abstraction system that describes selective concepts of a domain and it can be used to resolve problems related to that domain. If there is a piece of the model that is not reflected in the code, it should be removed.

Finally, the domain model is the base of the common language in a project. This common language in DDD is called ubiquitous language and it should have the following things:

• Class names and their functions related to the domain
• Terms to discuss the domain rules included on the model
• Names of analysis and design patterns applied to the domain model

The ubiquitous language should be used by all the members of the project, including developers and domain experts, so the developers should be able to describe all the tasks and functions.

It is absolutely necessary to use this language in all the discussions between the team, such as meetings, diagrams, or documentation, but this language was not born in the first iteration of the process, meaning that it can take many iterations of refactoring having the model, language, and code synchronized. If, for example, the developers discover that a class from the domain should be renamed, they cannot refactor this without refactoring the name on the domain model and the ubiquitous language.

The ubiquitous language, domain model, and code should evolve togetheras a single knowledge block.

There is controversial concept on DDD. Eric Evans says that it is necessary for the domain expert to use the same language as the team, but some people do not like this idea. Usually, the domain experts do not have knowledge of object-oriented concepts or microservices because they are too abstract for non-developers. Anyway, DDD says that if the domain expert does not understand the domain model, it is because there is something wrong with it.

There are diagrams in the domain model, but Evans suggests using text as well, because diagrams do not explain the concepts properly. Also, the diagrams should be superficial; if you want to see more details you have the code for it.

Some projects are affected by the connection between the domain model and the code. This happens because there is a pision between analysis and design. The analysts make a model independent of the design and the developers cannot develop the functionalities because some information is missing. In addition, they cannot talk with the domain expert. The development team will not follow the model and, in the end, the domain model will not be updated and it will not work. Therefore, the project will not meet the requirements.

To sum up, DDD works to achieve the software development as an iterative process of refinement of the model, design, and code as a single task in a block.

Using domain-driver design in microservices

As we said before, DDD meets the microservice's needs perfectly. A common problem with microservices appears because they have decentralized data management; this has advantages but can be problematic sometimes.

The concept model between two services will be different, and it can cause problems in huge companies. For example, a user can differ depending on the service, the attributes for each service regarding the user can differ and, also, the attribute semantic can differ.

It is even more complex when, in a big company, the application evolves a lot and has updates for many years. Each service can have different attributes for the user and, generally, they do not match. So, a great way to solve this is using DDD.

As microservices do, DDD pides a complex domain into different contexts, making relationships between them and asking for the collaboration of all the members to get a ubiquitous language in a particular domain and bounded context, iterating this process until they achieve a real concept regarding the problem.

Evans suggests designing each microservice as a DDD-bounded context so that it will provide a logical boundary for microservices inside a system. Every single microservice (or team working on it) will be responsible for that part of the system, and it will give clearer and maintainable code.

Michael Pl?d gave more ideas about how DDD can help microservices. There are four significant areas regarding building microservices:

• Strategic design: This is basically bounded context, but context maps and other patterns are important too. A context map should show all the bounded contexts of the project and their relationships with each other; it also describes the contract between them. The context map is very useful for monolithic applications wanting to move into microservices.
• Internal building blocks: This refers to using tactical patterns, such as aggregates, entities, or repositories, when designing the inside of a bounded context.
• Large-scale structures: This is used to create a structure using evolving order and responsibility layers. This is a concept in microservices too. In huge projects, it is helpful to create large-scale structures into boundary contexts. They should be designed to evolve inpidually.
• Distillation: Distilling a core domain from an already grown system is very useful when migrating a monolithic application into microservices. The most important part should be identifying and extracting the core domain, along with the iteration process of identifying a subdomain, extracting it from the core, and refactoring.

To sum up, microservices and DDD match perfectly, but it is necessary to have a larger scope and understand more than the boundary contexts.