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: The model and architecture of the program mutually determine each other. The model is at the heart of the language spoken by all development team members. The model is distilled knowledge. Let's dwell on each method in more detail. - the close relationship between the model and the software implementation ensures that the analysis done is reflected in the final program. The model and the architecture of the program are mutually defining - 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. The model underlies the language spoken by all members of the development team Each team member should start from the model and use the same terminology. A single language allows you to identify inaccuracies and inconsistencies during the application development to show what was chosen/misnamed. A model is distilled knowledge that enables us to convey our way of thinking about a subject. This method can be expressed in the allocation of general concepts and the establishment of connections between them. Further, we will return to these concepts more than once and consider the relationship between them because the correct use of these principles helps create programs with a wide range of capabilities. 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: Establish a link between the model and its implementation. Introduce Model-Based Language Develop an information-intensive model Distill the model 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. With close interaction between specialists in the team, the developed model is constantly being improved and forces programmers to master the fundamental principles of the area for which they write programs and not just mechanically implement functions. Thus, by participating in the process, developers weed out all unnecessary information and can work the model into a more useful form. 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

Flow

The Graph

2021 - HackerNoon Contributor of the Year - INNOVATION

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Software Architecture

2021 - HackerNoon Contributor of the Year - COMPUTER-SCIENCE

2021 - Rick Sanchez of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

An Introduction to Domain-Driven Design

An Introduction to Domain-Driven Design

Too Long; Didn't Read

Coins Mentioned

Sergey Golitsyn

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

An Introduction to Domain-Driven Design

Too Long; Didn't Read

Coins Mentioned

Sergey Golitsyn

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES