Introduction about Domain Driven Design

Hi, it's been a while since I wanted to write about Domain-Driven Design when I finally made up my mind and got started.

First Part: What is Domain Driven Design?

Domain-Driven Design, abbreviated DDD, was first introduced in 2003 by Eric Evans in his book Domain-driven design. This approach has attracted a lot of attention from the software community in recent years. In principle, DDD is a kind of thinking or approach for the production and development of large software with many and complex processes and rules, which from the analysis to the coding of a product with us, in principle, gives us ideas in both strategic and technical parts (Mr. Eric Evans himself talks more about strategic concepts in his book) And its main focus is on the core software business that we want to write about, which is the domain of adventure. In fact, DDD work starts with a business problem (Problem Domain).

Mr. Eric Evans's own definition of a domain is as follows: "The domain that the user applies to the application".

As I have said so far, we have found that DDD is very useful for products that have a complex business, so using it in small and simple projects or projects that only need to store and read information and do not have a specific business, may only increase the time and cost of the project and does not have a special advantage.

DDD also affects other aspects of the software development process, for example, there is a particular emphasis on constructive and optimal interaction between programmers and domain experts called business experts. This is why creating a common language called Ubiquitous Language on domain concepts is essential. We see this common language both in the analysis documents and in the code. In principle, one of the powers of DDD is the use of a common language. For example, look at the two images below, the first image is a scenario for sending and delivering pizza, and the second image is the implementation of the same scenario method. As we can see in both images there is an attempt to use a common language. (Pictures taken from The Anatomy Of Domain Driven Design)

Picture 1: (Pizza Delivery Scenario Documentary)

Picture 2: (Implementation of pizza delivery scenario)

Whenever DDD is mentioned, remember it crunching everything, It means that it crunched things down so that it can deal with them more easily, Such as Knowledge Crunching, or breaking the domain towards a subDomain, or providing solutions to divide the software into separate and independent sections, as well as the relationship of these sections to each other. This allows the software development process to be done in parallel between several teams and also enables system architects to use different architectures and technologies in different departments. If I want to talk more about SubDomains, I can say that they are divided into 3 categories: 

1- Core Domain: The main domain of knowledge and the problem we are dealing with is called the Core Domain. Most of the effort and cost of each company on the main domain, even many companies put their skilled forces on this part to work. In principle, the key to the success of any project is successful in the Core Domain.

2- Supporting Domain & Generic Domain: During a project, we may encounter parts that do not constitute the core of the business, but their existence is necessary for the main work of the domain to reach the goal, and we can even remove these parts from other companies. Let's buy. Like sending an email or SMS ...

In fact, the selection of sub-domains is a completely relative issue and has no rules and regulations. In fact, there is no definite right or wrong choice and it depends entirely on the team.

All the concepts that have been proposed so far were in the problem space and we have not yet entered the solution space. In essence, recognizing subdomains or common language .... is a problem in the definition space (problem space) and not in the solution space.

In this article, I tried to mention some of the basic and general concepts related to DDD. Now, in the next part, I will try to talk more about strategic and technical concepts and enter more into the solution space.

.