January 29, 2015 at 18:22Monolithic system VS many independent modules on the example of the parable of the elephant and sages
This article is basically a freeware retelling of a fragment of Eric Evans' book, “Object-Oriented Design,” in which he discusses Separate Ways and Bounded Context.
Suppose there is the following situation: several development groups are working on the same project, but solve different problems. For example, the project is a chip designer, and the first team implements the function of calling the chip, and the second calculates the cost of the chip. Question: what’s better to do - 1) allow both teams to “boil in their own juice”, receiving two modules at the output, the code of which practically does not intersect anywhere, or 2) establish communication between the two teams, make them work together and get a single output monolithic system?There is no universal answer to this question (“yes” or “no”) and the analogy with the elephant and sages will help us find the answer in this situation.
Here, the elephant is a complex subject area, and the sages are programmers.
Six gray-haired sages
converged from different countries.
Unfortunately, everyone was blind,
But he shone with his mind.
They explore the elephant
Appear in Hindustan.
One stroked the side of the elephant.
Satisfied with that,
he said: “Truth is now
How it is visible on a day:
The thing that we call an elephant,
Sheer wall!”
And he took the third trunk in his hands
And shouted: “Friends!
Our question is much simpler.
I am sure of this!
This elephant is a living creature,
Namely a snake! ”
The fourth sage grabbed
One of the elephant’s legs
and importantly said: “This is the trunk,
The picture is clear to me!
An elephant is a tree that will bloom,
When spring comes! ”
Meanwhile, the sixth of them made it
to the tail.
And he laughed at how
simple the truth was.
“Your elephant is a rope. If not,
Sew my mouth! ”
And as you know, the sages
Inherent stubborn disposition. Having
unleashed the argument, they
hardly reached the point of reprisal.
But no one knew the truth,
Although he was somewhat right.
If a subprogram of a team of programmers (sages) interacts with a specific part of a subject area (with the feet of an elephant), then it does not need to know the entire subject area (elephant) as a whole. At the same time, if they simplify this part of the subject area, discarding all that is superfluous (turning the elephant's legs into trees), they will receive a code that even someone who is little familiar with the subject area (who does not know what the elephant is) can understand. In addition, if the subject area is too complex, then when you try to grasp the immensity with your inner gaze, the programmer will fall into a cognitive stupor and the development speed will drop by an order of magnitude. But, on the other hand, this approach complicates the interaction between the individual parts of the program.
Compare both approaches. So, the advantages of large contexts (monolithic systems):
• various user operations are interconnected more smoothly and naturally, when as many different objects and operations as possible are covered by one unified model;
• it is easier to understand one connected model than two different ones and the level of display between them;
• broadcast between two models may be difficult (or even impossible);
• Common language stimulates clear interaction in the development team.
Advantages of small contexts (many heterogeneous modules):
• communication costs between developers are reduced (since there are fewer communications themselves);
• CONTINUOUS INTEGRATION is easier to perform in small groups with small code bases;
• in larger contexts, more universal and abstract models may be required, requiring rarely encountered developer qualifications;
• Small models can cater for special needs or correspond to the jargon of specialized user groups, as well as highly specialized dialects of the UNIFIED LANGUAGE (UBIQUITOUS LANGUAGE).
It should also be noted that theoretically a snake, trees and a rope can evolve into an elephant. If, for example, the specification of the program changes and it turns out that the elephant can walk, then the trees may well turn into legs. However, not all so simple. The case when the parts of the subject area do not intersect anywhere is idealized; in practice, most likely this is not so. Suppose two teams of programmers work with the trunk of an elephant, but the first team is interested in the fact that the trunk has the properties of a living creature, and their trunk is a snake, and the second team is interested in the ability of the trunk to splash water, and they have a trunk - a water hose. Over time, by pure chance, both development teams realized that the snake of the first team and the second hose describe the same phenomenon, after which the second team decided to replace the hose with a snake spitting water. And this will require two-week refactoring. From my own experience, I’ll say that no one will let you understand for two weeks what if the project has not started to sink under the burden of technical debts, but even then you will solve more pressing problems these two weeks than turning a hose into a spitting snake . Thus, in the realities of Russian development, if you do not initially begin to move in the direction of a monolithic model, then it will be almost impossible for you to switch to it, while leaving monolithic is not a problem. rather than turning a hose into a spitting snake. Thus, in the realities of Russian development, if you do not initially begin to move in the direction of a monolithic model, then it will be almost impossible for you to switch to it, while leaving monolithic is not a problem. rather than turning a hose into a spitting snake. Thus, in the realities of Russian development, if you do not initially begin to move in the direction of a monolithic model, then it will be almost impossible for you to switch to it, while leaving monolithic is not a problem.
If you have chosen the path of many non-interconnected modules, then remember the following proverb: “If three teams of programmers are developing a compiler, then they will get a three-pass algorithm at the output.” Beware of this. The architecture of the program should reflect the subject area, not the internal structure of your company!
PS This article was born as an answer to a small holivar in this article . If real life examples are interesting, I recommend reading the article Uncontrolled violation of the principle of multilevel .
Suppose there is the following situation: several development groups are working on the same project, but solve different problems. For example, the project is a chip designer, and the first team implements the function of calling the chip, and the second calculates the cost of the chip. Question: what’s better to do - 1) allow both teams to “boil in their own juice”, receiving two modules at the output, the code of which practically does not intersect anywhere, or 2) establish communication between the two teams, make them work together and get a single output monolithic system?There is no universal answer to this question (“yes” or “no”) and the analogy with the elephant and sages will help us find the answer in this situation.
Here, the elephant is a complex subject area, and the sages are programmers.
Six gray-haired sages
converged from different countries.
Unfortunately, everyone was blind,
But he shone with his mind.
They explore the elephant
Appear in Hindustan.
One stroked the side of the elephant.
Satisfied with that,
he said: “Truth is now
How it is visible on a day:
The thing that we call an elephant,
Sheer wall!”
And he took the third trunk in his hands
And shouted: “Friends!
Our question is much simpler.
I am sure of this!
This elephant is a living creature,
Namely a snake! ”
The fourth sage grabbed
One of the elephant’s legs
and importantly said: “This is the trunk,
The picture is clear to me!
An elephant is a tree that will bloom,
When spring comes! ”
Meanwhile, the sixth of them made it
to the tail.
And he laughed at how
simple the truth was.
“Your elephant is a rope. If not,
Sew my mouth! ”
And as you know, the sages
Inherent stubborn disposition. Having
unleashed the argument, they
hardly reached the point of reprisal.
But no one knew the truth,
Although he was somewhat right.
If a subprogram of a team of programmers (sages) interacts with a specific part of a subject area (with the feet of an elephant), then it does not need to know the entire subject area (elephant) as a whole. At the same time, if they simplify this part of the subject area, discarding all that is superfluous (turning the elephant's legs into trees), they will receive a code that even someone who is little familiar with the subject area (who does not know what the elephant is) can understand. In addition, if the subject area is too complex, then when you try to grasp the immensity with your inner gaze, the programmer will fall into a cognitive stupor and the development speed will drop by an order of magnitude. But, on the other hand, this approach complicates the interaction between the individual parts of the program.
Compare both approaches. So, the advantages of large contexts (monolithic systems):
• various user operations are interconnected more smoothly and naturally, when as many different objects and operations as possible are covered by one unified model;
• it is easier to understand one connected model than two different ones and the level of display between them;
• broadcast between two models may be difficult (or even impossible);
• Common language stimulates clear interaction in the development team.
Advantages of small contexts (many heterogeneous modules):
• communication costs between developers are reduced (since there are fewer communications themselves);
• CONTINUOUS INTEGRATION is easier to perform in small groups with small code bases;
• in larger contexts, more universal and abstract models may be required, requiring rarely encountered developer qualifications;
• Small models can cater for special needs or correspond to the jargon of specialized user groups, as well as highly specialized dialects of the UNIFIED LANGUAGE (UBIQUITOUS LANGUAGE).
It should also be noted that theoretically a snake, trees and a rope can evolve into an elephant. If, for example, the specification of the program changes and it turns out that the elephant can walk, then the trees may well turn into legs. However, not all so simple. The case when the parts of the subject area do not intersect anywhere is idealized; in practice, most likely this is not so. Suppose two teams of programmers work with the trunk of an elephant, but the first team is interested in the fact that the trunk has the properties of a living creature, and their trunk is a snake, and the second team is interested in the ability of the trunk to splash water, and they have a trunk - a water hose. Over time, by pure chance, both development teams realized that the snake of the first team and the second hose describe the same phenomenon, after which the second team decided to replace the hose with a snake spitting water. And this will require two-week refactoring. From my own experience, I’ll say that no one will let you understand for two weeks what if the project has not started to sink under the burden of technical debts, but even then you will solve more pressing problems these two weeks than turning a hose into a spitting snake . Thus, in the realities of Russian development, if you do not initially begin to move in the direction of a monolithic model, then it will be almost impossible for you to switch to it, while leaving monolithic is not a problem. rather than turning a hose into a spitting snake. Thus, in the realities of Russian development, if you do not initially begin to move in the direction of a monolithic model, then it will be almost impossible for you to switch to it, while leaving monolithic is not a problem. rather than turning a hose into a spitting snake. Thus, in the realities of Russian development, if you do not initially begin to move in the direction of a monolithic model, then it will be almost impossible for you to switch to it, while leaving monolithic is not a problem.
If you have chosen the path of many non-interconnected modules, then remember the following proverb: “If three teams of programmers are developing a compiler, then they will get a three-pass algorithm at the output.” Beware of this. The architecture of the program should reflect the subject area, not the internal structure of your company!
PS This article was born as an answer to a small holivar in this article . If real life examples are interesting, I recommend reading the article Uncontrolled violation of the principle of multilevel .