what is Domain Driven Design ( ddd )

domain driven design (ddd) 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 very common in huge projects.

eric evans introduced some concepts that are necessary to understand to learn how domaindriven 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, 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.

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 together as 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 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 division 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.