Get best of the week

What can I learn about Domain Driven Design in 10 minutes?

They say that you can endlessly look at the fire, observe how others work, and also study DDD (Domain Driven Design, domain-specific design). But if you have only 10 minutes, you can read this article and go to the very tops, and then with a smart look, nod your head during a small talk.

We twisted and reviewed DDD from different angles, together with Andrei Ratushny, technical director of Ugra Internet Solutions.





About the company: Ugra Internet Solutions is a company that is engaged in the automation of business processes in the commercial and public sectors. Located in the city of Khanty-Mansiysk. In development 12 people.

1. What is DDD, can be explained even to a child (or a marketer)


DDD is an approach that aims to study the subject area of ​​the enterprise as a whole or any individual business processes. This is an excellent approach for projects in which the complexity (complexity) of the business logic is quite large. Its use is designed to reduce this complexity as much as possible.

Outside of the DDD approach, when a programmer writes code, he pays more attention to technologies and infrastructure, for example, how to send a message, how to receive it, encode it, save it to a database, which database.

The DDD approach suggests that all this, of course, is important, but secondary. Business is more important and should come first. And to make this whole thing work together, DDD teaches us (developers) to speak the same language with business. Not in a programming language, but in a business language. This is called in the DDD Ubiquitous language.

2. DDD Chip - Bounded Context


Bounded Context is a key DDD tool; it is an explicit boundary within which a domain model exists. It maps a single language into a software model. It is on the basis of contexts that you can divide the code into modules / packages / components so that changes in each of them have a minimal (or zero) effect on the others.

For developers, this approach allows you to make changes to the code without fear that somewhere in another place something will break (for example, change something at the checkout and not worry that something will fall off from the couriers because of this).

For team leaders, this approach allows us to significantly parallelize the work of teams (s), which can significantly accelerate the work on the project.

Besides a limited context, there are all sorts of things like context maps, a single language, relations between contexts, translation maps ... uhhh! You won’t tell about it in 10 minutes, but you can read the “green” book.

3. General books on DDD: red, blue and green


DDD is a pretty old approach. Its use seems reasonable and quite justified, but for some reason it is still not widespread, little is said about it at conferences. What is wrong with this DDD?

There is an assumption that the main problem is the lack of training materials. The whole theory is described in several books: red , blue and green . They say that there is “another red book” , but few have seen it yet :) The

red and blue books are so hard to perceive that somewhere in the middle I want to throw the book out the window shouting: “Enough of this shit from me, see this incomprehensible DDD! I’ll go and do as I can. ” And this is only about theory, with materials on practice it is even more complicated.

Therefore, if you still decide to start studying literature on DDD, it is best to start with a green book. In it, Vaughn Vernon runs through the tops of the approach and, with simple examples, shows its advantages. They say that the translation turned out to be doubtful, so it is better to read in the original.

4. How to understand that it is time to apply DDD


Count the number of use cases for your system. If they are in the region of 10-15, then the business logic is not so complicated, and you can not steam, do not use any DDD.

If you have 30-50 or more UX cases, and they overlap very much, it makes sense to think about using DDD at least in some part of the system.

5. How to implement DDD in the company from the bottom up


Imagine that you are a developer who likes DDD, and you think that in your company this approach can be applied to make people happy.

Starting a guerrilla introduction of DDD alone is hard. First, knowledge may not be enough to start the process. Secondly, the dudes from your team may think that you are doing stupid things and will break everything by stuffing sticks into the wheels.

It’s better to start the implementation by creating an initiative group: try the approach together, understand the nuances, and understand in practice.

Only then can you go to an architect or technical engineer to explain the value to him. But remember that DDD is not needed everywhere. DDD solves specific problems, so it is very important not to overdo it.

The approach has a side effect: if people even begin to strive for DDD, then they will already begin to act in the paradigm of “Divide, divide, reduce connectivity and follow the business logic.” And from this, positive changes will begin: somewhere the code will be better written, somewhere the speed will increase. This knowledge does not have to turn into code in contexts and other DDD artifacts. The code may remain the code, but it will become better, and the speed and quality will increase.

6. How to implement DDD in the company from top to bottom


  1. Make sure that this approach will help in a particular case.
  2. Find a person in the team who has architectural skills (he will help determine where in the system the seams to be cut).
  3. Invite DDD practitioners to teach you.
  4. . ! . , .

7. DDD


Of course, through practice. Just do not tell the person in advance that you are teaching him DDD, do not scare ahead of time.

Let the person come and receive the tasks. Do not tell him that it is DDD, let him just do it. He will do based on how he understands the solid and all that. Then, when he will hand over the work, he needs to say: “Dear dude, it seems to work, but it needs to be redone,” and explain to him why.

Do not force to read or learn everything purposefully. Be interactive in this regard. So a person in 3-5 months will begin to understand the basic principles of DDD: from the point of view of implementation, from the point of view of theory. He will begin to understand patterns even earlier by approach artifacts - context maps. At first, people will not understand anything, but gradually they will be cut, and some will even read books.

8. I am able to DDD - an unimportant line for the resume in Russia


If you are in Russia and know DDD - this is cool. But it is far from the fact that the knowledge of DDD itself is useful in the work. Rather, it will serve as an indicator for the employer about your high level of development as a developer. After all, the skills that you acquire by studying the DDD approach develop you as a programmer and as a designer (architect).

But if you are thinking about moving abroad, then such a line in the resume can have a positive impact. Abroad, the DDD community is much larger, and the approach itself is much more popular than ours. Especially in Europe.

9. The relationship of DDD with facial hair


Observation: People who understand DDD wear beards. Does this mean that having a beard is a prerequisite for success in DDD? What do you think?

10. Useful materials on DDD



« ». , . , Miro, , Amazon, Microsoft, . .

:

More articles:


All Articles