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 automates 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 the Ubiquitous language in DDD.

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 to parallelize the work of teams (s) to a large extent, which can significantly speed up the project.

In addition to the 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. DDD General Books: 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 so far few have seen it 🙂

The red and blue books are so heavy in perception that somewhere in the middle I want to throw the book out the window shouting: “Enough of this shit from me, what for 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 her Vaughn Vernon goes over the top of the approach and shows simple advantages with simple examples. 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 with the creation of 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. Step by step refactor the necessary parts of the system. Remember! Not all parts need such refactoring. Isolation of models and code processing is necessary only where the business will get the maximum benefit from it.

7. How to teach a person DDD without his knowledge

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 get the puzzles. Do not tell him that it is DDD, let him just do it. He will do it based on how he understands solidity 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 a fact that the knowledge of DDD itself will be 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

Podcast Nothing of the Thing. Dear reader, this article was written under the impression of the release of our podcast. We became interested in what the culture looks like, teams and processes are being built in different technology companies like Miro, Yandex, Amazon, Microsoft, Food. Therefore, we met with the guys from there and chatted on these topics.

Now you can listen to it:

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *