Nikolai Grebnev (CUSTIS) - What is DDD? - report from the ADD conference
There is such an ADD (Application Developer Days) conference where they like to discuss all sorts of architectural pieces for software development, usually these pieces also end with xDD - DDD, TDD, MDD, etc.
For example, at the last conference, we wondered what is DDD (Domain Driven Design)?
And Nikolay Grebnev from CUSTIS - got up and answered.
Video report:
')
Download the video here (0.73 GB)
Presentation of the report:
Text of the report
This is such a set of systems, attitudes and approaches that determines our way of development. In 2002, Martin Fowler published the book Enterprise Application Architecture Patterns . The book is currently a classic on the architecture of the development of corporate applications. In particular, Martin cites three templates for organizing business logic in a project:
A transaction scenario is such a way of organizing business logic, when we divide all business logic into several business operations - in fact, procedures that somehow are arranged inside there, which receive some data at the input, and at the output we get the result and some changes in the system, for example records in the database or something else.
This is how we get the structuring of business logic and with a rather complicated logic, with a large amount of application - this method does not work well, because we get macaroni code, “save pastes”, and so on.
The table module is a slightly different approach. It lies in the fact that we distinguish classes, entities that denote a table of concepts of interest to us, in fact, a database table.
All classes have some operations, they already know something, encapsulate something in themselves. As a rule, they encapsulate work with a database. In particular, they can contain methods: add, delete, get everything, and some others. Well and with each entity we work, requesting from tables. Obviously, we have no connection between the tables, and somehow we build them manually in our program. In fact, if someone worked with MS Visual Studio or MS technologies in general, this is RecordSet & DataSet, until 2008 these were the main technologies for working with data.
Well, the domain model . It differs from the previous options presented in that we are building a full-fledged domain model. Which consists of entities that have behaviors that interact with other entities, have explicitly defined relationships, and so on. The figure shows a model of the automation domain, for example, a library.
The domain model basically consists of entities, there are still many different objects, such as services, value objects, and the like. Well, if we are talking about the object model of the domain, and it also turns out that in corporate IP, most subject areas have an object structure, then for the most part they consist of entities.
Entities are concepts that have an identity. Those. Each instance of an entity can be identified and differs from the others, and encapsulates the state of the object and its behavior. This means that in no way can we externally inform the object about changing its state, bringing it to a non-consistent state, or forcing it to behave in a way that it should not behave.
This template is the most successful for use in complex IP. Because it is the most successful way to structure the subject area and contributes to our understanding.
As the development of this pattern in 2003, Eric Ewans 's book "Object-Oriented Design" (originally in Domain Driven Design structured complex software systems). This book contains not only the description of such a template as a subject area, but also a certain set of approaches that show us how to work with such a set, build and how we finally get this domain model. That's what Eric Evans tells us about DDD.
This is, firstly, the processing of knowledge . Those knowledge that we have about the subject area, they need to be analyzed, from them it is necessary to allocate the actual subject area.
Secondly, it is a single language . Any model gives us some terminology that forms its own language, and with which we can work, speak it, write.
And design by model (Model Driven Design) . This is the most technical part of DDD. Which means that we directly map our invented domain model to the code, namely it, and not any other.
Well, let's look at each of these parts in more detail. One would think that DDD, judging by the name, is a design, and we want to get a model from it. In fact, this is somewhat wrong. And in general, we can say that this is impossible. Because everything is a little more complicated. When we come to the subject area and want to automate it - we still do not know what model we have. And what's more, even those special analysts who work with it - they do not know what their model is. And we need not any kind of any model, but a model for our IP, most likely it is slightly different from the generally accepted domain model. There are either new concepts or other concepts that are more clearly limited and more formally defined and therefore the first step that we should do when developing in accordance with DDD is to process the knowledge of our subject area. After we have built some kind of domain representation in ourselves - we need to design a model, then directly with what we will work. After the model has been designed, we again return to the subject area and begin to consider it more deeply, in more detail, highlighting new entities, making the implicit, etc. explicit, and finally, when we did refactoring, we again return to the processing of knowledge , again we analyze what we have done and what can be changed, then build a model. And such an iterative process takes place.
As defined by its Eric Evans - is the search for abstract concepts that take into account the necessary details.
Necessary for the development of our IP, obviously.
Who performs this processing of knowledge?
Of course, the developers are guiding this process, because it is actually they who need it. And they know how the system will be arranged and what to do about it. Specialists of the subject area respectively tell how everything is arranged and give the necessary explanations.
EXAMPLE
Here is some example. I will tell what a model is. The simplest task is to calculate the salary of an employee in a given month. Anyone who has ever come across this will probably know that the salary is not as simple as it should be.
The subject matter expert tells us that
The ratio of the number of days worked to the number of working days in the month multiplied by the ratio of the employee’s salary to the number of working days in the month
We are building a model
Obviously, in the phrase there are such concepts as employee, month, number of working days, employee salary.
We ask a specialist what is a day off. We get the answer:
The working day when the employee was present at the workplace, while he had not yet quit.
We have a new entity, this is some DAY, obviously, it stands out clearly, has a relationship with the employee and with the month, has the attributes "work / holiday", "present".
Then the domain specialist recalls that the employee may still have holidays or he may be on sick leave and there everything is different, there is a different rate, other problems.
We are drawing such a model, and already here we see that something is wrong with us - a lot of connections. It is logical to ask a question. And from where we can find out that our employee was present at work, whether he was on vacation or on sick leave. And the specialist answers us: “from the time sheet”. He had not mentioned him before, because for him it was absolutely natural. This is not something that needs a separate mention, but by processing knowledge, analyzing the system, we have identified such an entity and, accordingly, the model we get is much more understandable when we have an employee, we have his time sheet that has the following functions The following methods:
And it is in this timesheet that all the logic associated with the calculation of these days is encapsulated. Because inside it is all quite difficult to organize - anyway, this is our simplified model. And we all encapsulate all this in the timesheet and after that we can calmly talk and mention this notion when talking with any specialist, because we explicitly selected it and explicitly said.
A single language is the language we get as a result of DDD. This is a language in which all project participants communicate. This does not mean that we have built some kind of model, then thrown it out and start talking, as it were, with some new terms, explaining something on our fingers. No, we have a domain model, namely in its terms, its relations, its behavior, we must talk, discuss the structure of technical tasks and so on. The language is based on the domain model, it must clearly follow from it. And he also checks the domain model. If the domain model that you have built is very, very complex and it is difficult for you to use it in the language, you always want to use other terms and other sentences - this means that your model is not properly built. A very good way to check whether you have a good model or not is to try using its terms in Russian. Just talking in terms of this model, and if you don’t have any discomfort there, then you are fine there. And this model is used in all documents. Those. we are not just building some models, talking. No, it is on the basis of these models that official documents should be built, including TK, requirements, system architecture, etc. And if not strange, it is the same language that should be used in the code. Those. if we used this model in Russian when talking with people, then we should use the same model when talking with a computer.
We have a domain model, and it generates terminology. Since it consists of concepts, entities and behaviors. Here is an example of the definition of the word "terminology" from the dictionary.
Terminology is a system of terms - words of a scientific and technical LANGUAGE with a certain, clearly limited meaning.
This means that the word of the language enables us to use this model, the language generated by it for communication with each other. And the fact that the terms we have clearly limited meanings - gives us the opportunity to use these terms in the code.
The most difficult part of DDD. It is difficult for technical reasons due to imperfect tools for everything, inertia of thinking and many other reasons. That's what design by model is (according to Eric Evans).
Design by Model (Model Driven Development) - architecture design, in which the most precise correspondence between a certain subset of program elements and model elements is observed.
This means if we had a domain model
- and we start building a program for it.
And once - we get just such a model. In the middle we have business logic. We see that completely different concepts are used. Here we have some datasets. Data viewers, commands, connectors, and other things that were not even mentioned in the domain model. I'm not saying that if you try to speak this language with people from the subject area, with people for whom you are writing this program, then you will have to explain for a very long time what you mean.
And here we see that we have one model, the program is different. The program model operates with some concepts (dataset, connectivity, etc.), and the domain model - books, authors, publisher, reader, etc.
This means that our domain model should be thrown out, it was, of course, useful, the people who built it knew the subject area better, but most likely it would lose its relevance very quickly.
But this is not the case the domain model has a much wider application. From the definition of Evans:
Model Driven Design (MDD) is a direct projection of the domain language onto an object-oriented programming language.
Those. It will be wrong if we have the concept Author in the model, and in the code we have it is a dataset string, and even untyped and not explicitly present.
Let me give you an example. Let's build the following task:
The usual task for the accounting system, and it is easy to understand that the history is divided by divisions, that we need to be able to get an employee of the division. A unit has a function such as enrolling an employee for a date. Let's try to write it in the code, as is usually the case.
I don’t even work with datasets, but quite a model based on a certain ORM, which even supports Linq, but somewhat different from the real one. Any programmer, as you understand, could do this - take all the old intervals that were stored in the database in order to enlist employees - all intervals, starting from a certain date - take and delete. At the same time, see what happens. Not only does some kind of deletion appear, because before that there was nothing about any kind of deletion and secondly, we have DeparmentHistroyRepository. Well, probably, the concept of “repository” we can somehow build into the subject area, more or less, but such a new entity, which is actually a table and stores information by department, is already very bad for the model.
What do we do next? Then we must complete the previous period for the existing ones, in which he worked and say a day earlier that the employee no longer works in the division.
Well, look, you see, there are no such words as select, select, where, from, DataEnd, DepartmentHistoryRepository - in general there was no domain model. We only have these concepts in the code and we already see obvious discrepancies. And at the same time note that both of these operations are not present at all in the task, they are caused by our technical necessity.
And finally, we do the task itself, we create the essence itself.
At the same time, please note that we create this entity not at the department in general, strictly speaking this department submits someone to itself, but for some DepartmentHistoryRepository, most likely, that only programmers know this and that is not all. Then we call the method with a different name - “create new” (CreateNew) - why new? We do not create anything, we just enlist a person.
But in the case of Model Drive Design, it should look like this:
Here, for example - so. I specifically used the Russian language here in order to maximally approximate the correspondence of the domain model to the fact that we use in the code as much as possible. Further, even if there is some kind of logic there, it should be encapsulated in this method and designed in more detail. Then, when we write all the code in this style. Firstly, it can be easily read by a person, even if he is not familiar with a programming language, there will be more or less Russian written there. Unlike Russian, the difference with C # is that parentheses, commas and periods, etc. replaced by various interjections, prepositions and other connecting words.
I hope I was able to briefly describe what DDD is. Let me remind you that this is the processing of knowledge when we develop a subject area - this is a single language in which we should always communicate with each other. And modeling based on the subject area, meaning that we have not just developed this model, but to implement it directly in the code.
This is an effective way to deal with complexity. Indeed, in complex systems, a good domain model in itself helps to deal with complexity. And when we directly introduce it into the code, when programmers, analysts, domain experts all work in the same terms, and the programmer always doesn’t need to think how to translate it from “authors-readers” into datasets. This is significant, this is not something that a programmer should not think about at all, we just explicitly separate it. Separate from what is. And this is a single language. Do not underestimate the value of this thing, because this single language has a direct display of code, well, almost any phrase that we speak in this language, we can immediately check, even purely speculative. Is it possible to implement it in code or not. As a rule, when our code is written in several other terms, it takes considerable time. Moreover, a single language in itself, the presence of a language in itself, makes it possible to significantly improve the development of requirements. It is a well-known fact that the quality of a project and the speed of a project depend on a good definition of its Scope, for the most part not something there, namely, what we will do, and what we will not and define it without a single terminology, constantly, each time re-agreeing about what we are talking about is quite difficult.
And all this ultimately gives a low cost of development and maintenance, which is naturally very important in the development of corporate information systems.
I described so many advantages. And why can we not use DDD, why can we refuse it? We have some problems. Not everything is as good as we would like.
Organizational problems, for example, separation of analysis and design, it can be both explicitly - there are analysts and developers in the team who do not participate in the analysis at all, and not explicitly, just in the person’s head, even if he doesn’t participate in the analysis, but for himself, he first analyzes and builds some model, and then tries to implement it. And he is trying to realize it, as a rule, somehow differently. In this case with DDD, we should immediately think about how we will implement the model. And for example, if we understand that we cannot implement the model in this form, performance is very important to us. Then we will have to bring it explicitly, explicitly, in explicit terms on the basis of which we will talk later to the customer and to all other project participants, these new concepts are hard enough, and usually some experience is required.
Also, a purely administrative problem is often encountered when a developer is removed from analysis, and developers in general may never see for whom they do all this when a separate department of analysts is allocated. This is not so bad, but just analysts, as a rule, do not represent and cannot build an architecture from beginning to end, since they are not familiar with the necessary number of technical details. And due to this, we have to - the model that the analyst will build the developer will not be able to inject into the code, because it does not take into account the specifics of the implementation. And that is why it is necessary to involve precisely those who will directly build the architecture of the application and write code on the basis of its design of the model, so that we can immediately say whether we can do this or not. And even if someone was wrong, so that it would be immediately possible to fix it promptly.
Lack of DDD experience. It must be said that DDD is primarily a change of consciousness within the project team, developers, so that they are involved in the analysis, also analysts, so that they look more closely at how this will be implemented. So are the project managers who need to be involved in development and analysis. Well, Model Driven Design itself, which is a fundamental part of DDD, requires some kind of breaking up, because we are trying to implement what we have come up with in the code, you always want to get somewhere, take a dataset here, do something still.
Well, a lot of technical problems. All problems are related to Model Driven Design. First of all, these are bad tools in order to store data somehow - obviously, some means must be used in object-oriented languages. Typically, data in corporate systems are stored in relational databases. This forces us to choose some kind of converter from a relational database to our object model. There are even many industrial tools for this, such as Hibernate and other ORMs, but they all have problems. They are difficult to use and they are far from ideal, so that we can abstract away from the fact that we have some kind of database down there, often this is so important that it generally leads to the need to abandon DDD, otherwise there will be no system as long as we fight bad tools. Well, also in other areas and technologies, in distributed systems, for example, we have even more problems in DDD, by directly mapping our model into code, we are starting to get into the code completely different models: interaction models between distributed systems, interaction model with a database, are just program models that are completely unnecessary there.
All this can lead to the fact that the use of DDD becomes either impossible or undesirable, or very expensive.
Well, that's all, I hope that I did some brief introduction to DDD. And that you really have tools for designing on the basis of models, then you will try to use this approach.
Question: What is the difference between OOP approach and DDD?
Answer: OOP approach does not call us to build a model, OOP approach is a combination of data with behavior, and this may not be related to the subject area. The datasets I cited, Datariders, are also OOP approaches, simply there the objects are different and the behavior is different and they are not related to the problem we are solving and are caused by technological reasons. And DDD is a set of approaches and attitudes that force us to build these objects in a certain way, directly by the way they work in the real world. At the same time, DDD urges us not to somehow build our model, which we will later reflect on the PLO, and also highlighting from it all the concepts clearly and more closely to what we are talking about. A good example that says that we are working on DDD is when we say a phrase, we set a task that looks exactly the same in the code, no comments, nothing is written right in the code. If it says “calculate the salary of employees”, then the code will also say “calculate the salary of employees”. If it is written that “the salary of employees is the number of working days * on salary + the number of days on vacation * average annual salary,” then in exactly the same terms, the truth can be in English, if it is more convenient for the language, although this, of course, also bad - it should be written. And if we have written “select from db order by ... group by ...", this is already a sign that we have already moved far from Model Driven Design and our model no longer corresponds to what we are implementing.
: , (, . ) ?
: , , .
: . ?
: . . Facebook, , – . , , -, , . , . . , , , .
: overdraft, ?
: , DDD . , , ( ..). , , , , . . , , , , DDD, . , , – , .
: . , , .
: . - . , , . , DDD . , , . , , , , 10 , – -, . , , -, – , , . , : - «»? , , , – , , . « » — , – . , ! , , , , .
For example, at the last conference, we wondered what is DDD (Domain Driven Design)?
And Nikolay Grebnev from CUSTIS - got up and answered.
Video report:
')
Download the video here (0.73 GB)
Presentation of the report:
Text of the report
What is DDD (Domain Driven Design)?
This is such a set of systems, attitudes and approaches that determines our way of development. In 2002, Martin Fowler published the book Enterprise Application Architecture Patterns . The book is currently a classic on the architecture of the development of corporate applications. In particular, Martin cites three templates for organizing business logic in a project:
- Transaction script
- Table module
- Domain Model
A transaction scenario is such a way of organizing business logic, when we divide all business logic into several business operations - in fact, procedures that somehow are arranged inside there, which receive some data at the input, and at the output we get the result and some changes in the system, for example records in the database or something else.
This is how we get the structuring of business logic and with a rather complicated logic, with a large amount of application - this method does not work well, because we get macaroni code, “save pastes”, and so on.
The table module is a slightly different approach. It lies in the fact that we distinguish classes, entities that denote a table of concepts of interest to us, in fact, a database table.
All classes have some operations, they already know something, encapsulate something in themselves. As a rule, they encapsulate work with a database. In particular, they can contain methods: add, delete, get everything, and some others. Well and with each entity we work, requesting from tables. Obviously, we have no connection between the tables, and somehow we build them manually in our program. In fact, if someone worked with MS Visual Studio or MS technologies in general, this is RecordSet & DataSet, until 2008 these were the main technologies for working with data.
Well, the domain model . It differs from the previous options presented in that we are building a full-fledged domain model. Which consists of entities that have behaviors that interact with other entities, have explicitly defined relationships, and so on. The figure shows a model of the automation domain, for example, a library.
The domain model basically consists of entities, there are still many different objects, such as services, value objects, and the like. Well, if we are talking about the object model of the domain, and it also turns out that in corporate IP, most subject areas have an object structure, then for the most part they consist of entities.
Entities are concepts that have an identity. Those. Each instance of an entity can be identified and differs from the others, and encapsulates the state of the object and its behavior. This means that in no way can we externally inform the object about changing its state, bringing it to a non-consistent state, or forcing it to behave in a way that it should not behave.
This template is the most successful for use in complex IP. Because it is the most successful way to structure the subject area and contributes to our understanding.
As the development of this pattern in 2003, Eric Ewans 's book "Object-Oriented Design" (originally in Domain Driven Design structured complex software systems). This book contains not only the description of such a template as a subject area, but also a certain set of approaches that show us how to work with such a set, build and how we finally get this domain model. That's what Eric Evans tells us about DDD.
This is, firstly, the processing of knowledge . Those knowledge that we have about the subject area, they need to be analyzed, from them it is necessary to allocate the actual subject area.
Secondly, it is a single language . Any model gives us some terminology that forms its own language, and with which we can work, speak it, write.
And design by model (Model Driven Design) . This is the most technical part of DDD. Which means that we directly map our invented domain model to the code, namely it, and not any other.
Well, let's look at each of these parts in more detail. One would think that DDD, judging by the name, is a design, and we want to get a model from it. In fact, this is somewhat wrong. And in general, we can say that this is impossible. Because everything is a little more complicated. When we come to the subject area and want to automate it - we still do not know what model we have. And what's more, even those special analysts who work with it - they do not know what their model is. And we need not any kind of any model, but a model for our IP, most likely it is slightly different from the generally accepted domain model. There are either new concepts or other concepts that are more clearly limited and more formally defined and therefore the first step that we should do when developing in accordance with DDD is to process the knowledge of our subject area. After we have built some kind of domain representation in ourselves - we need to design a model, then directly with what we will work. After the model has been designed, we again return to the subject area and begin to consider it more deeply, in more detail, highlighting new entities, making the implicit, etc. explicit, and finally, when we did refactoring, we again return to the processing of knowledge , again we analyze what we have done and what can be changed, then build a model. And such an iterative process takes place.
What is the processing of knowledge?
As defined by its Eric Evans - is the search for abstract concepts that take into account the necessary details.
Necessary for the development of our IP, obviously.
Who performs this processing of knowledge?
- Domain Specialists
- System developers (not in the sense of programmers, analysts, testers, project managers, but it is important that there should be those who will write the code, who understand how the system architecture will look like)
Of course, the developers are guiding this process, because it is actually they who need it. And they know how the system will be arranged and what to do about it. Specialists of the subject area respectively tell how everything is arranged and give the necessary explanations.
EXAMPLE
Here is some example. I will tell what a model is. The simplest task is to calculate the salary of an employee in a given month. Anyone who has ever come across this will probably know that the salary is not as simple as it should be.
The subject matter expert tells us that
The ratio of the number of days worked to the number of working days in the month multiplied by the ratio of the employee’s salary to the number of working days in the month
We are building a model
Obviously, in the phrase there are such concepts as employee, month, number of working days, employee salary.
We ask a specialist what is a day off. We get the answer:
The working day when the employee was present at the workplace, while he had not yet quit.
We have a new entity, this is some DAY, obviously, it stands out clearly, has a relationship with the employee and with the month, has the attributes "work / holiday", "present".
Then the domain specialist recalls that the employee may still have holidays or he may be on sick leave and there everything is different, there is a different rate, other problems.
We are drawing such a model, and already here we see that something is wrong with us - a lot of connections. It is logical to ask a question. And from where we can find out that our employee was present at work, whether he was on vacation or on sick leave. And the specialist answers us: “from the time sheet”. He had not mentioned him before, because for him it was absolutely natural. This is not something that needs a separate mention, but by processing knowledge, analyzing the system, we have identified such an entity and, accordingly, the model we get is much more understandable when we have an employee, we have his time sheet that has the following functions The following methods:
- Get the number of days worked
- Get the number of days on vacation
- Get the number of days on sick leave, etc.
And it is in this timesheet that all the logic associated with the calculation of these days is encapsulated. Because inside it is all quite difficult to organize - anyway, this is our simplified model. And we all encapsulate all this in the timesheet and after that we can calmly talk and mention this notion when talking with any specialist, because we explicitly selected it and explicitly said.
A single language is the language we get as a result of DDD. This is a language in which all project participants communicate. This does not mean that we have built some kind of model, then thrown it out and start talking, as it were, with some new terms, explaining something on our fingers. No, we have a domain model, namely in its terms, its relations, its behavior, we must talk, discuss the structure of technical tasks and so on. The language is based on the domain model, it must clearly follow from it. And he also checks the domain model. If the domain model that you have built is very, very complex and it is difficult for you to use it in the language, you always want to use other terms and other sentences - this means that your model is not properly built. A very good way to check whether you have a good model or not is to try using its terms in Russian. Just talking in terms of this model, and if you don’t have any discomfort there, then you are fine there. And this model is used in all documents. Those. we are not just building some models, talking. No, it is on the basis of these models that official documents should be built, including TK, requirements, system architecture, etc. And if not strange, it is the same language that should be used in the code. Those. if we used this model in Russian when talking with people, then we should use the same model when talking with a computer.
We have a domain model, and it generates terminology. Since it consists of concepts, entities and behaviors. Here is an example of the definition of the word "terminology" from the dictionary.
Terminology is a system of terms - words of a scientific and technical LANGUAGE with a certain, clearly limited meaning.
This means that the word of the language enables us to use this model, the language generated by it for communication with each other. And the fact that the terms we have clearly limited meanings - gives us the opportunity to use these terms in the code.
Design by model.
The most difficult part of DDD. It is difficult for technical reasons due to imperfect tools for everything, inertia of thinking and many other reasons. That's what design by model is (according to Eric Evans).
Design by Model (Model Driven Development) - architecture design, in which the most precise correspondence between a certain subset of program elements and model elements is observed.
This means if we had a domain model
- and we start building a program for it.
And once - we get just such a model. In the middle we have business logic. We see that completely different concepts are used. Here we have some datasets. Data viewers, commands, connectors, and other things that were not even mentioned in the domain model. I'm not saying that if you try to speak this language with people from the subject area, with people for whom you are writing this program, then you will have to explain for a very long time what you mean.
And here we see that we have one model, the program is different. The program model operates with some concepts (dataset, connectivity, etc.), and the domain model - books, authors, publisher, reader, etc.
This means that our domain model should be thrown out, it was, of course, useful, the people who built it knew the subject area better, but most likely it would lose its relevance very quickly.
But this is not the case the domain model has a much wider application. From the definition of Evans:
Model Driven Design (MDD) is a direct projection of the domain language onto an object-oriented programming language.
Those. It will be wrong if we have the concept Author in the model, and in the code we have it is a dataset string, and even untyped and not explicitly present.
Let me give you an example. Let's build the following task:
Enroll the employee in the unit, starting from the specified date.
The usual task for the accounting system, and it is easy to understand that the history is divided by divisions, that we need to be able to get an employee of the division. A unit has a function such as enrolling an employee for a date. Let's try to write it in the code, as is usually the case.
I don’t even work with datasets, but quite a model based on a certain ORM, which even supports Linq, but somewhat different from the real one. Any programmer, as you understand, could do this - take all the old intervals that were stored in the database in order to enlist employees - all intervals, starting from a certain date - take and delete. At the same time, see what happens. Not only does some kind of deletion appear, because before that there was nothing about any kind of deletion and secondly, we have DeparmentHistroyRepository. Well, probably, the concept of “repository” we can somehow build into the subject area, more or less, but such a new entity, which is actually a table and stores information by department, is already very bad for the model.
What do we do next? Then we must complete the previous period for the existing ones, in which he worked and say a day earlier that the employee no longer works in the division.
Well, look, you see, there are no such words as select, select, where, from, DataEnd, DepartmentHistoryRepository - in general there was no domain model. We only have these concepts in the code and we already see obvious discrepancies. And at the same time note that both of these operations are not present at all in the task, they are caused by our technical necessity.
And finally, we do the task itself, we create the essence itself.
At the same time, please note that we create this entity not at the department in general, strictly speaking this department submits someone to itself, but for some DepartmentHistoryRepository, most likely, that only programmers know this and that is not all. Then we call the method with a different name - “create new” (CreateNew) - why new? We do not create anything, we just enlist a person.
But in the case of Model Drive Design, it should look like this:
Here, for example - so. I specifically used the Russian language here in order to maximally approximate the correspondence of the domain model to the fact that we use in the code as much as possible. Further, even if there is some kind of logic there, it should be encapsulated in this method and designed in more detail. Then, when we write all the code in this style. Firstly, it can be easily read by a person, even if he is not familiar with a programming language, there will be more or less Russian written there. Unlike Russian, the difference with C # is that parentheses, commas and periods, etc. replaced by various interjections, prepositions and other connecting words.
I hope I was able to briefly describe what DDD is. Let me remind you that this is the processing of knowledge when we develop a subject area - this is a single language in which we should always communicate with each other. And modeling based on the subject area, meaning that we have not just developed this model, but to implement it directly in the code.
Why we might need DDD.
This is an effective way to deal with complexity. Indeed, in complex systems, a good domain model in itself helps to deal with complexity. And when we directly introduce it into the code, when programmers, analysts, domain experts all work in the same terms, and the programmer always doesn’t need to think how to translate it from “authors-readers” into datasets. This is significant, this is not something that a programmer should not think about at all, we just explicitly separate it. Separate from what is. And this is a single language. Do not underestimate the value of this thing, because this single language has a direct display of code, well, almost any phrase that we speak in this language, we can immediately check, even purely speculative. Is it possible to implement it in code or not. As a rule, when our code is written in several other terms, it takes considerable time. Moreover, a single language in itself, the presence of a language in itself, makes it possible to significantly improve the development of requirements. It is a well-known fact that the quality of a project and the speed of a project depend on a good definition of its Scope, for the most part not something there, namely, what we will do, and what we will not and define it without a single terminology, constantly, each time re-agreeing about what we are talking about is quite difficult.
And all this ultimately gives a low cost of development and maintenance, which is naturally very important in the development of corporate information systems.
I described so many advantages. And why can we not use DDD, why can we refuse it? We have some problems. Not everything is as good as we would like.
Cons DDD
Organizational problems, for example, separation of analysis and design, it can be both explicitly - there are analysts and developers in the team who do not participate in the analysis at all, and not explicitly, just in the person’s head, even if he doesn’t participate in the analysis, but for himself, he first analyzes and builds some model, and then tries to implement it. And he is trying to realize it, as a rule, somehow differently. In this case with DDD, we should immediately think about how we will implement the model. And for example, if we understand that we cannot implement the model in this form, performance is very important to us. Then we will have to bring it explicitly, explicitly, in explicit terms on the basis of which we will talk later to the customer and to all other project participants, these new concepts are hard enough, and usually some experience is required.
Also, a purely administrative problem is often encountered when a developer is removed from analysis, and developers in general may never see for whom they do all this when a separate department of analysts is allocated. This is not so bad, but just analysts, as a rule, do not represent and cannot build an architecture from beginning to end, since they are not familiar with the necessary number of technical details. And due to this, we have to - the model that the analyst will build the developer will not be able to inject into the code, because it does not take into account the specifics of the implementation. And that is why it is necessary to involve precisely those who will directly build the architecture of the application and write code on the basis of its design of the model, so that we can immediately say whether we can do this or not. And even if someone was wrong, so that it would be immediately possible to fix it promptly.
Lack of DDD experience. It must be said that DDD is primarily a change of consciousness within the project team, developers, so that they are involved in the analysis, also analysts, so that they look more closely at how this will be implemented. So are the project managers who need to be involved in development and analysis. Well, Model Driven Design itself, which is a fundamental part of DDD, requires some kind of breaking up, because we are trying to implement what we have come up with in the code, you always want to get somewhere, take a dataset here, do something still.
Well, a lot of technical problems. All problems are related to Model Driven Design. First of all, these are bad tools in order to store data somehow - obviously, some means must be used in object-oriented languages. Typically, data in corporate systems are stored in relational databases. This forces us to choose some kind of converter from a relational database to our object model. There are even many industrial tools for this, such as Hibernate and other ORMs, but they all have problems. They are difficult to use and they are far from ideal, so that we can abstract away from the fact that we have some kind of database down there, often this is so important that it generally leads to the need to abandon DDD, otherwise there will be no system as long as we fight bad tools. Well, also in other areas and technologies, in distributed systems, for example, we have even more problems in DDD, by directly mapping our model into code, we are starting to get into the code completely different models: interaction models between distributed systems, interaction model with a database, are just program models that are completely unnecessary there.
All this can lead to the fact that the use of DDD becomes either impossible or undesirable, or very expensive.
Well, that's all, I hope that I did some brief introduction to DDD. And that you really have tools for designing on the basis of models, then you will try to use this approach.
Questions:
Question: What is the difference between OOP approach and DDD?
Answer: OOP approach does not call us to build a model, OOP approach is a combination of data with behavior, and this may not be related to the subject area. The datasets I cited, Datariders, are also OOP approaches, simply there the objects are different and the behavior is different and they are not related to the problem we are solving and are caused by technological reasons. And DDD is a set of approaches and attitudes that force us to build these objects in a certain way, directly by the way they work in the real world. At the same time, DDD urges us not to somehow build our model, which we will later reflect on the PLO, and also highlighting from it all the concepts clearly and more closely to what we are talking about. A good example that says that we are working on DDD is when we say a phrase, we set a task that looks exactly the same in the code, no comments, nothing is written right in the code. If it says “calculate the salary of employees”, then the code will also say “calculate the salary of employees”. If it is written that “the salary of employees is the number of working days * on salary + the number of days on vacation * average annual salary,” then in exactly the same terms, the truth can be in English, if it is more convenient for the language, although this, of course, also bad - it should be written. And if we have written “select from db order by ... group by ...", this is already a sign that we have already moved far from Model Driven Design and our model no longer corresponds to what we are implementing.
: , (, . ) ?
: , , .
: . ?
: . . Facebook, , – . , , -, , . , . . , , , .
: overdraft, ?
: , DDD . , , ( ..). , , , , . . , , , , DDD, . , , – , .
: . , , .
: . - . , , . , DDD . , , . , , , , 10 , – -, . , , -, – , , . , : - «»? , , , – , , . « » — , – . , ! , , , , .
Source: https://habr.com/ru/post/142491/
All Articles