What is the "domain model"?
Hi, Habr.
Today I went to the #school channel in the Russian-language GoCommunity in Slack and found an interesting dialogue there . This dialogue brought me to some thoughts about how colleagues interpret the concept of “domain model (domain)” .
As it turned out, there are quite a lot of incorrect or not quite accurate, and sometimes quite inaccurate interpretations of this term, which essentially distorts it. The idea of ​​this article was born around this dialogue. Details under the cut.
So, the developer asked the following question in the community:
To which another programmer gave the following answer:
After reading this, I suddenly realized why there are so many disputes in the organization of the business logic layer, and why many people fail to put into practice such approaches as Clean Architecture , etc. After all, what does “architecture with an anemic model” mean?
')
If you try to find such a concept in the network, you most likely will not find it, because there is no such architecture. There is the concept of “AnemicDomainModel” , and if you turn to the same Fowler, it turns out that this is just a procedural approach to creating an application architecture (hello Fortran, ALGOL, COBOL, BASIC, Pascal and C). This, in essence, is what the author of the answer calls “architecture with an anemic model . ”
Then the next question arises, is the “anemic model” a model in essence? I think not, and here's why.
The truth is that the domain model is not a data model, unlike the “database model” or “API response model . ” The domain model has a very specific definition . Moreover, it is wrong to interfere with the database model, which is essentially a data model .
When it comes to the domain model, it is the conceptual model that is meant. And this is a set of concepts of the subject area and the relations between them (that is, a set of behavior and data). In general, the main feature that distinguishes one domain model from another is precisely the set of business rules.
Yes, the conceptual model can work with data that is presented in different forms (data from the database or API responses), but the essence will not change, the behavior is paramount . We pass data to the model input to get a certain result on the output. This result is achieved through the implementation of business logic within the model (in other words, the application of business rules). I find here an analogy with mathematical models and modeling of technological processes (hello, student years).
When you call data structures “domain model,” you voluntarily or not substitute concepts. This leads to the fact that often business logic is spread throughout the application. In fact, the domain model in this case is the same smeared set of functions, operating with data structures.
In the case of the development of medium and large applications, misunderstanding or mixing of these concepts, as a rule, leads to a number of problems and questions already at the start of system development, not to mention long-term support. Among them, for example, there are such common questions as:
However, if you have a simple CRUD, i.e. in fact, the interface to the database, problems most likely will not. If you are writing an infrastructure-level library (for example, for working with a network or from the same database), problems should also not arise. This is because there is an RFC and all the “business rules” have long been clear, and the logic has long been clear. You can write a simple procedural program, and everything will be fine anyway.
If we go back to the fact that the dialogue about domain models has arisen in the Go community, I would say so. Since Go is a multi-paradigm language and supports a number of the most successful OOP concepts (Composition, Interfaces), you should not ignore them when modeling the subject area and write code exclusively in a procedural style, as if you are working with BASIC or C.
Properly interpreting the concept of “domain model”, it becomes quite obvious why it is often common to isolate business logic into a separate layer. It also becomes clear how to select this layer and implement Clean Architecture or any other variation of it. Selecting a separate layer, we essentially create a library that implements the conceptual model in the form of program code. As a result, business logic becomes encapsulated within this library, rather than being spread over the entire application (as with a pure procedural approach).
Of course, the understanding of these concepts will not save you from mistakes in design, will not make you an ideal developer or system architect and will not teach you to do everything right the first time. Here not only theory is important, but also practice. However, once you understand the concepts correctly and interpret the definitions, many things will become much clearer and simpler for you.
Be attentive to the definitions, study them deeper than just reading diagonally. Very often we are lazy and grab information in pieces, after which distortion will certainly occur. Do not forget to come back and bring up in memory things that seem obvious to you for a long time, and always refer to the original sources and call things by their names.
All good! Thanks for attention.
Ps. I will be glad to hear constructive criticism, as well as your vision of what a “domain model” is. Links to original sources are welcome.
UPD: The article is not an attempt to loosely interpret the concept of a “domain model” and invest in this concept to me alone. I want to convey this: The meaning of this concept has long been invested, and it is described in detail in books and articles on ComputerScience. The article is an attempt to convey to the colleagues in the workshop the importance of correct perception of these very concepts without distorting their meaning (This is important, because in practice it will allow writing more meaningful code).
UPD2: I am not an enterprise-theoretician theorist. I'm a practicing developer like you. I write code every day and talk about these things in order to make my code better, and customers happier. If, in your opinion, I have distorted the original meaning, share links to original sources as well as indicate where I put it incorrectly, so that I can fix it.
UPD3: Because Many interpret the term “subject area” differently, cite some examples of subject areas, so that there is no confusion and no substitution of concepts. The subject area always depends on which problem you solve through application development:
Today I went to the #school channel in the Russian-language GoCommunity in Slack and found an interesting dialogue there . This dialogue brought me to some thoughts about how colleagues interpret the concept of “domain model (domain)” .
As it turned out, there are quite a lot of incorrect or not quite accurate, and sometimes quite inaccurate interpretations of this term, which essentially distorts it. The idea of ​​this article was born around this dialogue. Details under the cut.
The question of architecture.
So, the developer asked the following question in the community:
Tell me how to do the architecture correctly, let's say I made a label in the database, asked for reforms to generate a reform model for me, can I use this model in my application as a domain model, or better create my own domain model and make an adapter that will give me exactly my domain model creating it from a reform model? ”
To which another programmer gave the following answer:
The simplest is architecture with an anemic model. This is when DB model = domain model = API response model. The rich domain model is a rare beast and usually degenerates into anemic. Anemic means DTO structure. the usual set of attributes (fields) without methods. Logic degenerates into a set of functions operating with such dto. Fowler at times considers such an architecture antipattern. But then a good microservice solution, etc.
After reading this, I suddenly realized why there are so many disputes in the organization of the business logic layer, and why many people fail to put into practice such approaches as Clean Architecture , etc. After all, what does “architecture with an anemic model” mean?
')
If you try to find such a concept in the network, you most likely will not find it, because there is no such architecture. There is the concept of “AnemicDomainModel” , and if you turn to the same Fowler, it turns out that this is just a procedural approach to creating an application architecture (hello Fortran, ALGOL, COBOL, BASIC, Pascal and C). This, in essence, is what the author of the answer calls “architecture with an anemic model . ”
Domain model (domain).
Then the next question arises, is the “anemic model” a model in essence? I think not, and here's why.
The truth is that the domain model is not a data model, unlike the “database model” or “API response model . ” The domain model has a very specific definition . Moreover, it is wrong to interfere with the database model, which is essentially a data model .
When it comes to the domain model, it is the conceptual model that is meant. And this is a set of concepts of the subject area and the relations between them (that is, a set of behavior and data). In general, the main feature that distinguishes one domain model from another is precisely the set of business rules.
Yes, the conceptual model can work with data that is presented in different forms (data from the database or API responses), but the essence will not change, the behavior is paramount . We pass data to the model input to get a certain result on the output. This result is achieved through the implementation of business logic within the model (in other words, the application of business rules). I find here an analogy with mathematical models and modeling of technological processes (hello, student years).
What is fraught with the substitution of concepts?
When you call data structures “domain model,” you voluntarily or not substitute concepts. This leads to the fact that often business logic is spread throughout the application. In fact, the domain model in this case is the same smeared set of functions, operating with data structures.
In the case of the development of medium and large applications, misunderstanding or mixing of these concepts, as a rule, leads to a number of problems and questions already at the start of system development, not to mention long-term support. Among them, for example, there are such common questions as:
- "- Where to validate the data?"
- "- How to avoid circular dependencies?"
- "- Is“ this ”business logic at all?"
- "- Where do we keep business logic?"
- etc.
However, if you have a simple CRUD, i.e. in fact, the interface to the database, problems most likely will not. If you are writing an infrastructure-level library (for example, for working with a network or from the same database), problems should also not arise. This is because there is an RFC and all the “business rules” have long been clear, and the logic has long been clear. You can write a simple procedural program, and everything will be fine anyway.
If we go back to the fact that the dialogue about domain models has arisen in the Go community, I would say so. Since Go is a multi-paradigm language and supports a number of the most successful OOP concepts (Composition, Interfaces), you should not ignore them when modeling the subject area and write code exclusively in a procedural style, as if you are working with BASIC or C.
Properly interpreting the concept of “domain model”, it becomes quite obvious why it is often common to isolate business logic into a separate layer. It also becomes clear how to select this layer and implement Clean Architecture or any other variation of it. Selecting a separate layer, we essentially create a library that implements the conceptual model in the form of program code. As a result, business logic becomes encapsulated within this library, rather than being spread over the entire application (as with a pure procedural approach).
Of course, the understanding of these concepts will not save you from mistakes in design, will not make you an ideal developer or system architect and will not teach you to do everything right the first time. Here not only theory is important, but also practice. However, once you understand the concepts correctly and interpret the definitions, many things will become much clearer and simpler for you.
Let's sum up.
- It is not correct to call “data” a domain model.
- The domain model is a conceptual model that includes both behavior and data. It can be encapsulated in a separate layer, or it can be spread throughout the application.
- “An anemic model architecture” is nothing more than a procedural approach to creating an application architecture in which the domain model is spread throughout the application
Be attentive to the definitions, study them deeper than just reading diagonally. Very often we are lazy and grab information in pieces, after which distortion will certainly occur. Do not forget to come back and bring up in memory things that seem obvious to you for a long time, and always refer to the original sources and call things by their names.
All good! Thanks for attention.
Ps. I will be glad to hear constructive criticism, as well as your vision of what a “domain model” is. Links to original sources are welcome.
UPD: The article is not an attempt to loosely interpret the concept of a “domain model” and invest in this concept to me alone. I want to convey this: The meaning of this concept has long been invested, and it is described in detail in books and articles on ComputerScience. The article is an attempt to convey to the colleagues in the workshop the importance of correct perception of these very concepts without distorting their meaning (This is important, because in practice it will allow writing more meaningful code).
UPD2: I am not an enterprise-theoretician theorist. I'm a practicing developer like you. I write code every day and talk about these things in order to make my code better, and customers happier. If, in your opinion, I have distorted the original meaning, share links to original sources as well as indicate where I put it incorrectly, so that I can fix it.
UPD3: Because Many interpret the term “subject area” differently, cite some examples of subject areas, so that there is no confusion and no substitution of concepts. The subject area always depends on which problem you solve through application development:
- Ticket Booking (If you are a booking system developer)
- Banking (If you are a developer of banking applications)
- Operating systems (If you are an OS developer)
- Cloud Infrastructure Management (If you are a k8s developer)
- Virtualization (If you are a docker developer)
- Performance Monitoring (If you are a Prometheus / Grafana developer)
Source: https://habr.com/ru/post/453906/
All Articles