Hello everyone. Have you come across DDD (domain-driven design)? Once, my team lead advised me to study this approach for creating Software. And I began to dive into this topic. So what is it?
DDD is the area of knowledge or activity in which an organization or users use a program in a domain. Quite often, subject areas are associated with physical reality. To make a valuable program for users and businesses, it is necessary to use the knowledge related to this particular subject area. This is a critical point. But the breadth and volume of knowledge required can be overwhelming.
How does one deal with this? Models come to the rescue. They are designed to cope with this load. A correctly selected model allows you to concentrate on the problem and simplify the solution of the problem. A domain model is not some drawn diagram, it is an idea that the graph should reflect.
According to Eric Evans, there are three fundamental ways to choose a model in Domain-Driven Design:
Let's dwell on each method in more detail.
The model and the architecture of the program are mutually defining - the close relationship between the model and the software implementation ensures that the analysis done is reflected in the final program.
The model underlies the language spoken by all members of the development team - for me, this principle is one of the main ones, and in all my projects, I try to move to a common language within the team.
Each program has an "algorithmic" part. This is the part that is capable of solving a problem from a specific subject area. But is it enough to understand the algorithm without knowledge of the subject area? Is it possible to write the correct algorithm for a particular program without diving and figuring out the main points of the subject area? In most software projects, developers focus on technical, technology, and mathematical algorithms, leaving the subject area to analysts and game designers.
Even the most talented programmers are not very eager to learn a lot about the subject area they work in. Engineers prefer clear-cut technical specifications. Working with the subject area seems to them to be something unnecessary and just a waste of time. As a result, it happens that a programmer invents "the wheel" or does complex things, spending a lot of unnecessary time, when immersion in the subject area could help him save a lot of energy and lead him in the right direction.
To successfully model a system based on a subject model, you must:
What does it mean to establish a link between a model and its implementation? When developing a solution, a connection must be established between architecture and the real world. The architecture and model must reflect the natural world and solve problems from the real world. Introduce a language based on a model - when introducing a single language, the whole team is on the same wavelength and communicates clearly. By using common terminology, client and server programmers quickly find a common language and agree on APIs.
Developing an information-intensive model is not an easy task.
We need more than just containers of data, and we need a holistic methodology for solving complex problems. In designing any system, you will encounter discoveries and surprises and introduce new concepts. It is crucial to get rid of secondary ideas immediately, notice what has become irrelevant, keep the model clean, and be open to change. In an intense brainstorming session, you will evaluate and consider hundreds of options. It is essential to test them because many cases can be pushed even verbally during a discussion.
During the development/design of the system, all specialists must constantly process knowledge. For example, in banking projects, a business analyst works with numbers and processes thousands of formulas related to the subject area. In turn, professional modeling specialists immerse themselves in the subject area and process the information flow. They are looking for a core, a fundamental "wave" in it. They are trying to find the most straightforward display of this entire mountain of information. They distill domain knowledge. But knowledge processing never happens alone. For this purpose, developers and analysts work together and process data into a usable form.
In "waterfall" melodic, usually the subject area specialists passed the data to the analyst, who, in turn, processed the information and then gave the result to the programmers, who wrote the program. In this approach, analysts do not have the opportunity to learn something from programmers, Or programmers cannot gain additional knowledge about the subject area. All knowledge flows in one direction but does not accumulate.
It is beneficial for an excellent programmer to strive to abstract and build an extended model that can do more than is required. But if this is done without cooperation with a subject area specialist, then such programs will be without a deep logical connection with the way of thinking of the analyst and subject area specialist.
In an ideal world, a good model gives professionals a deeper understanding of the problem. Starting to write a new server, we do not always have all the sufficient information. It is impossible to know enough to write the perfect application. Knowledge related to the project is constantly scattered across various documents and memories of different people. In an already implemented program, part of the knowledge can be lost entirely, especially when only one person had it in his head. This is why teams must practice continuous learning. For developers, this means constantly improving their technical skills and improving their general domain modeling skills. This also includes a deep study of the subject area with which the team is working.
In the end, I believe that every developer or specialist in the company should try to dive into the subject area. This will help to design a more profound architecture that you will enjoy supporting in the future.
What do you think of this approach? Do you use DDD yourself in your work?
First published here