[Reprinted] Do you really understand the layered architecture? -- To friends who are "poisoned" by petshop

Do you really understand the layered architecture? -- Sources for friends who have been "poisoned" by petshop: Zhang Yang

Blind spots

The layered architecture on the. NET platform (called the "three-tier architecture" by many friends) seems to be a long-lasting topic. Many friends often analyze, discuss, debate, and even attack it. After carefully reading a large number of articles in this area, I think that many of my friends are biased towards understanding the layered architecture:

1. Not to understand the connotation of hierarchy from the perspective of nature, but to understand its appearance.

2. the layered architecture is too narrow-minded. It is only a few concepts, but not in-depth enough.

Many friends say that "layering" must be called "Dal", "BLL", and "presentation layer, we do not know that the "Dal" includes "data source architecture mode", "object-relational behavioral mode", and "object-relational structural mode, there are many specific modes in each aspect, such as "data source architecture", "table data Gateway", "row data Gateway", and "acitive record. Besides, we all know that "BLL" is a "business logic layer", but what is "business logic "? "BLL" can be built into three modes: "transaction script", "domain model", and "Table module". What do they mean? In addition, layers are not only divided into "data access layer", "business logic layer", and "presentation layer, are you familiar with concepts such as "service layer", "persistence layer", and "application control layer.

Most of the reasons for this are that most. NET platform developers (including me) understand that the layered architecture begins with Microsoft's petshop. Because petshop is an official demo, it is regarded by many. NET developers as a Bible and even a standard solution for hierarchical architecture on the. NET platform. I have seen many of my friends leave "layered architecture or the most classic petshop" in my blog, "Think about the credit layer or petshop", and "you are learning from petshop ".. Friends are so respectful of petshop, but ignore the fact that it is just a demo. To put it back, even if it is a practical project, it is unscientific to define an abstract concept through a specific project.

For example, if a person does not know what a cow is, he asks a dairy farm administrator, who moves out a cow and tells him: "This is a cow ". Since then, if someone asks him what a "Ox" is, he will tell others that "Ox" is a huge, clumsy, gentle character, with black and white patches on his body, there is also a big Mimi, which can be milked for drinking. One day, he heard that there was a bullfighting sport in Spain, and he was shocked: "How can this happen! Cool, How can I fight! And the ox is used for milking and drinking !"

In this story, what makes a mistake? He equals the abstract concepts of "a specific cow" and "cow. He believes that the ox is "a huge, clumsy, gentle personality, black and white plaque pattern, there is a big Mimi, can milk for people to drink ". We do not know that there are cattle, Buffalo, yak, bullfighting, beef cattle and other kinds of cattle in the world. He failed to create an abstract concept by looking at the essence through imagination, and made a "Blind Eye" error.

In fact, many of my friends have a one-sided or biased understanding of the layered architecture because they make the same mistake as the person in the story. At the beginning, we didn't know what a "layered architecture" was, so Microsoft gave us a petshop and said, "Look! ." So we suddenly realized: "Oh! This is a layered architecture !". In this way, the abstract concept of the "layered architecture", which has a great connotation and extension, and a specific demo is marked with an equal sign, this has also become the person in the story-we say that the layered architecture must be called dal and BLL, and our project must follow the petshop architecture ......

We were "poisoned" by petshop. But this is not Microsoft's fault, not petshop's fault, as in the story, we cannot blame the dairy farm administrator or the cow. We are wrong! When Microsoft gave us petshop, we should be aware in our mind that this is a demo of a layered architecture. Instead of understanding it as "this is a layered architecture ". We should study and think to grasp the essence of layered architecture, but we do not. Instead of being poisoned by petshop, We are poisoned by ourselves and our bad study habits. Let's just look at the appearance, or just look at the appearance, and then we suddenly final the layered architecture. However, they failed to see the essence through imagination. Therefore, we have also made a "one-leaf blind" mistake.

I have also made the above mistakes! Therefore, in the next article, I would like to share with my friends some of my experiences in reflecting on myself, hoping to help more friends get out of the blind eye as soon as possible ".

Insight into the nature of hierarchy

We can discuss how to stratify, the advantages and disadvantages of layering, and the value of layering ...... But before all this discussion, we need to figure out one thing: what is the essence of hierarchy? Or: How did layers come from? If this problem is not clear, our other discussions are like building a high platform on the sand float. If there is no solid foundation, it will be untenable.

To understand the nature of the hierarchy, we have to talk about the division of labor. The division of labor can be said to be the biggest improvement in labor productivity. The benefits of the initial division of labor are reflected in the "comparative advantage". Given their respective duties, each person can engage in the work they are best, in addition, the labor proficiency brought about by labor alone increases and reduces the loss during labor replacement, greatly improving labor productivity. However, with the development of society, we find that some special forms of division of labor can not only increase productivity, but also have some advantages! To understand these benefits, let's take a practical example.

Today is children's day. A mother wants to buy her daughter a cream cake as a gift. We know that cake needs flour, eggs, milk, and so on. It also needs a series of complicated processing and packaging processes, but this mother does not need to care about this, she just needs to go to a nearby supermarket to buy it directly. There is no chicken farm or dairy farm in the supermarket, and there is no farmer's uncle who grows wheat or a worker's master who bake cakes. This simple "buy cake" scenario can be expressed in about.

Figure 1. Cake Production Division

Figure 1 illustrates how a cake arrives at a customer. As you can see, making a cake is not a single task and requires a lot of division of labor. If you look at it from the bottom up, the main division of labor includes: planting and production of basic material materials, raw material processing, cake processing, and commercial sales. Not all division of labor is shown in this way. The division of labor has some characteristics. The following is a summary.

1. The lower layer does not know the existence of the upper layer. For example, a dairy factory produces milk. It does not have to know what milk is taken for. It may be bought by a cream factory for cream, or it may be bought by an ice cream factory for ice cream, it may also be acquired to make milk sugar. In short, it just completes its own responsibility-to produce milk, and has no knowledge of its upper layer. Similarly, the cream processing factory only produces cream, and it does not have to know whether the cream is taken as a cake or Moka coffee.

2. Each layer only knows the next layer (except the last layer, because the last layer does not have the next layer), but does not know the other lower layer. For example, a cake factory only needs to know how to extract flour, cream, and eggs from a flour mill, cream mill, and Egg Factory, you don't have to worry about how the flour and the cream come from.

It can be said that the division of labor in line with the above two points is the ideological source of the layered architecture. The following is a little more formal. The so-called stratified thinking is such a division of labor: it organizes the system according to different responsibilities into an orderly level. In addition to the top layer, each layer only provides several services for its adjacent upper layer, but does not know the existence of the upper layer. In addition to the bottom layer, each layer only calls services near the lower layer.

Therefore, the so-called "stratified thinking" is just a special form of division of labor. The layered concept in computer software architecture is a special case of applying this idea to software development, while the "Dal + BLL + PL" approach adopted by petshop is, it is just a special case of applying this idea to software development. For example, if the business of a system is very simple, just adding, deleting, modifying, and querying, then BLL will not work, and the "Dal + PL" approach will be well completed, which is also a good Hierarchical architecture. Another example is that if the business of a system is complex, you need to normalize the system, perform operations, and then sort it out, the "Dal + normalization layer + computing layer + arrangement layer + PL" layer architecture is also reasonable. If the interface exposed by a system BLL is too complicated, it is normal to add a "Facade service layer" between BLL and PL in the facade mode. Furthermore, if a system does not require data access, such as a calculator program, we just want to separate the representation from the business (computing function), then there will be no Dal, "BLL + PL" is reasonable. Therefore, the essence of a layered architecture is to "organize the system into an orderly hierarchy according to different responsibilities ......" This paragraph describes, rather than simply "dividing the system into Dal + BLL + PL", rather than "architecture by petshop ".

The following is an excerpt from Fowler's definition of hierarchy in patterns of enterprise application architecture:

When thinking of a system in terms of layers, you imagine the principal subsystem in the software arranged in some form of layer cake, where each layer rests on lower layer. in this scheme the higher layer uses various services defined by lower layer, but lower layer is unaware of the higher layer. furthemore, each layer usally hides its lower layers from the layers above.

-- Martin Fowler, patterns of enterprise application architecture, P17

The general translation is as follows:

When we say a system is a layered architecture, you can think of this software as a cake with many layers, each of which is placed on its next layer. The higher layer uses many lower-layer definitions and services, but the lower layer does not notice the existence of the higher layer. In addition, each layer hides a lower layer from its upper layer.

-- Martin Fuller, enterprise application architecture model, P17

However, one thing to declare here: Although "Dal + BLL + PL" is not equivalent to a layered architecture, it is just an instance. But at the same time, we need to clearly understand that this method is so popular that Microsoft's official examples are structured like this because for many systems, especially large and medium-sized MIS systems, this architecture should be prioritized. In this section, I have never criticized "Dal + BLL + PL". On the contrary, when developing a system, this approach can be prioritized, then we can make some improvements based on the characteristics of the system. What I have stressed in this section is that we cannot regard "Dal + BLL + PL" as the essence of a layered architecture, nor can we equate it with the concept of "layered architecture.

Advantages and disadvantages of Layered Architecture

On the basis of understanding the nature of the layered architecture, we can confidently analyze the advantages and disadvantages of the layered architecture. Let's talk little about it. In this section, we will go straight into the topic.

The advantages of layered architecture are as follows:

1. Remove developers' attention. Since a layer only calls the services provided by its adjacent next layer, as long as the APIS at the current layer and the APIS at the next layer are completely defined, when developing a layer, developers can focus on the ideas, models, and technologies used in this layer. This is equivalent to introducing the productivity improvement advantage brought by the division of labor into software development. Another example is buying a cake. As a supermarket, you only need to know the underlying API (how to obtain the cake from the cake factory) and the API that needs to be implemented on the current layer (sell the cake to the customer ), you don't have to worry about how to grow wheat, how to grind flour, how to make cream, and how to make cakes. In this way, supermarkets only need to carry out commercial operations, rather than industrial operations, so specific, will inevitably improve the business level.

2. lossless replacement. Imagine if a dairy farm goes down, will the cream processing factory go down? Of course not. It can quickly replace a dairy farm, because each dairy farm can provide the "milk" service. For another example, if one day the country has introduced a policy that requires all cream plants to import raw materials from qualified dairy farms, and the partner milk suppliers of a cream factory fail to pass the review, you only need to change the cooperation that has passed the review. In addition, the various links inside the cream factory do not need to change, because different dairy farms can provide the "milk supply" service. If the cream factory raises its own cattle to produce milk, once this policy is met, it will have to go to the relevant departments for review, adjust the corresponding business process, and take a long time. The same principle in the program is most often heard of as database migration.

3. Reduced inter-system dependencies. In the example of cake, if the machine is changed in the cake factory one day or the business process is adjusted, do customers need to care? Obviously, this is not necessary because the customer only calls the services provided by supermarkets. Supermarkets hide all the following industry details for customers. If every customer buys the same product, they need to know a series of details from raw material production to molding and then to sales. In another program, the presentation layer only calls services at the business layer. How many layers are there under the business layer? How does data come from? How to save it? Is it true or fabricated? Do not need to understand, which greatly reduces the dependencies between the various responsibilities of the system.

4. reuse. For example, you can go to this supermarket to buy things, or I can go to this supermarket to buy things. The cake factory can extract flour from the flour mill, or from the steamed bread factory. In this way, the same layer can provide services for different upper layers, achieving the purpose of reuse. Specific to the program, for example, the Meteorological Bureau produced and released a "service layer" to provide weather forecast information. In this way, websites such as Sina and Sohu can use the services provided by this service layer to create a weather forecast page. QQ can also use this service to add weather forecasts on its chat tools, you need to use the weather forecast function or call the service layer of the meteorological station ".

Let's talk about the advantages and disadvantages of the layered architecture:

1. Cascade modification problems. This problem is not a metaphor in reality, but I believe many friends in the program understand it. For example, in a human affairs management system, the personnel information can only be viewed by page. Now, you need to add a function that can be divided by department at the same time. For example, you can view "the first 50 people in the Sales Department", so that all layers of this function need to be modified.

2. Performance problems. Operations that were originally directly transferred are now transferred at different layers, which will inevitably lead to a decline in performance. For example, in the example of buying a cake. When customers enjoy the benefits of division of labor, they also need to bear the rise in cake prices caused by the distribution of departments on different layers. This is because the cost is increased by layering, such as transportation, coordination and management costs between different layers of departments.

Looking at the above analysis, the layered architecture has advantages and disadvantages. This must be because everything in the world has both advantages and disadvantages. Therefore, it is unwise and unscientific to take the "layered architecture" and "one stick to death" approach. To treat a layered architecture, we should clarify its nature and advantages and disadvantages, and then make rational analysis and choices based on the specific situation.

From the above analysis, we can see that the layered architecture can reduce the cost of changes in the layer, and is very sensitive to API changes. As mentioned in cascade modifications, the new requirement of "dividing departments while paging" is the API change. API changes are fatal to the layered architecture and are difficult to modify. Therefore, a simple judgment rule is: If frequent changes (or even whole-layer replacement) in your system layer are likely, and the API changes are unlikely, layers are used; if the API may change frequently, you need to use the layered architecture with caution.

Next

In fact, the main content I want to talk about is the first three sections. But there are still some things that I want to be nagging.

This article is not a technical article, so I will not mention technical details, but I just want to help you clarify your misunderstanding of layering. Recently I have read a lot of discussions about layered architecture (or L3 Architecture). Most of them are critical, and some even think that layered architecture is useless. I think the people who come up with this idea have roughly gone through the following stages: I have heard about layering, rough learning layering, imitating and using layering, being very uncomfortable, and criticizing.

In fact, any technology is objective and there is no error. The mistake lies in the fact that people are not using it correctly, or they are not using it properly. Just like we can't criticize that blades are not suitable for cutting forks, and we can't criticize that firewood knives are not suitable for shaving. If a technology wants to exert its power, the key must be to use it correctly. To use it correctly, we need to have a deep foundation, and we need to study hard and be diligent in thinking. This is not an overnight task. We must have persistent perseverance. We should strive to be a good man who is good at studying and grasping the essence of things, instead of a man who splits firewood with a blade and shave his beard with a knife, and then scolds the blades and knives as garbage.

The concept of hierarchy has never been first proposed in the software architecture. The networks we use on the Internet every day follow the OSI Layer 7 protocol. The design of the network structure is a model for the rational application of the concept of hierarchy. In addition, in many other engineering technology fields, stratified thinking is also common. Therefore, we should not regard hierarchy as the unique capabilities of computer people or even software developers. The technology that applies hierarchy to software architecture in those fields is still immature, and there are still many things waiting for us to do.

Finally, I strongly recommend a book called patterns of enterprise application architecture by Martin Fowler. I believe that after reading this book, we will greatly improve our understanding of the concept of hierarchy and the application and decision-making of specific models in hierarchy. You will understand that the original layering is not only "Dal", "BLL", but also how many internal things are there.

Wish everyone a happy 6th! :)

The layered architecture on the. NET platform (called the "three-tier architecture" by many friends) seems to be a long-lasting topic. Many friends often analyze, discuss, debate, and even attack it. After carefully reading a large number of articles in this area, I think that many of my friends are biased towards understanding the layered architecture:

1. Not to understand the connotation of hierarchy from the perspective of nature, but to understand its appearance.

2. the layered architecture is too narrow-minded. It is only a few concepts, but not in-depth enough.

Many friends say that "layering" must be called "Dal", "BLL", and "presentation layer, we do not know that the "Dal" includes "data source architecture mode", "object-relational behavioral mode", and "object-relational structural mode, there are many specific modes in each aspect, such as "data source architecture", "table data Gateway", "row data Gateway", and "acitive record. Besides, we all know that "BLL" is a "business logic layer", but what is "business logic "? "BLL" can be built into three modes: "transaction script", "domain model", and "Table module". What do they mean? In addition, layers are not only divided into "data access layer", "business logic layer", and "presentation layer, are you familiar with concepts such as "service layer", "persistence layer", and "application control layer.

Most of the reasons for this are that most. NET platform developers (including me) understand that the layered architecture begins with Microsoft's petshop. Because petshop is an official demo, it is regarded by many. NET developers as a Bible and even a standard solution for hierarchical architecture on the. NET platform. I have seen many of my friends leave "layered architecture or the most classic petshop" in my blog, "Think about the credit layer or petshop", and "you are learning from petshop ".. Friends are so respectful of petshop, but ignore the fact that it is just a demo. To put it back, even if it is a practical project, it is unscientific to define an abstract concept through a specific project.

For example, if a person does not know what a cow is, he asks a dairy farm administrator, who moves out a cow and tells him: "This is a cow ". Since then, if someone asks him what a "Ox" is, he will tell others that "Ox" is a huge, clumsy, gentle character, with black and white patches on his body, there is also a big Mimi, which can be milked for drinking. One day, he heard that there was a bullfighting sport in Spain, and he was shocked: "How can this happen! Cool, How can I fight! And the ox is used for milking and drinking !"

In this story, what makes a mistake? He equals the abstract concepts of "a specific cow" and "cow. He believes that the ox is "a huge, clumsy, gentle personality, black and white plaque pattern, there is a big Mimi, can milk for people to drink ". We do not know that there are cattle, Buffalo, yak, bullfighting, beef cattle and other kinds of cattle in the world. He failed to create an abstract concept by looking at the essence through imagination, and made a "Blind Eye" error.

In fact, many of my friends have a one-sided or biased understanding of the layered architecture because they make the same mistake as the person in the story. At the beginning, we didn't know what a "layered architecture" was, so Microsoft gave us a petshop and said, "Look! ." So we suddenly realized: "Oh! This is a layered architecture !". In this way, the abstract concept of the "layered architecture", which has a great connotation and extension, and a specific demo is marked with an equal sign, this has also become the person in the story-we say that the layered architecture must be called dal and BLL, and our project must follow the petshop architecture ......

We were "poisoned" by petshop. But this is not Microsoft's fault, not petshop's fault, as in the story, we cannot blame the dairy farm administrator or the cow. We are wrong! When Microsoft gave us petshop, we should be aware in our mind that this is a demo of a layered architecture. Instead of understanding it as "this is a layered architecture ". We should study and think to grasp the essence of layered architecture, but we do not. Instead of being poisoned by petshop, We are poisoned by ourselves and our bad study habits. Let's just look at the appearance, or just look at the appearance, and then we suddenly final the layered architecture. However, they failed to see the essence through imagination. Therefore, we have also made a "one-leaf blind" mistake.

I have also made the above mistakes! Therefore, in the next article, I would like to share with my friends some of my experiences in reflecting on myself, hoping to help more friends get out of the blind eye as soon as possible ".

Insight into the nature of hierarchy

We can discuss how to stratify, the advantages and disadvantages of layering, and the value of layering ...... But before all this discussion, we need to figure out one thing: what is the essence of hierarchy? Or: How did layers come from? If this problem is not clear, our other discussions are like building a high platform on the sand float. If there is no solid foundation, it will be untenable.

To understand the nature of the hierarchy, we have to talk about the division of labor. The division of labor can be said to be the biggest improvement in labor productivity. The benefits of the initial division of labor are reflected in the "comparative advantage". Given their respective duties, each person can engage in the work they are best, in addition, the labor proficiency brought about by labor alone increases and reduces the loss during labor replacement, greatly improving labor productivity. However, with the development of society, we find that some special forms of division of labor can not only increase productivity, but also have some advantages! To understand these benefits, let's take a practical example.

Today is children's day. A mother wants to buy her daughter a cream cake as a gift. We know that cake needs flour, eggs, milk, and so on. It also needs a series of complicated processing and packaging processes, but this mother does not need to care about this, she just needs to go to a nearby supermarket to buy it directly. There is no chicken farm or dairy farm in the supermarket, and there is no farmer's uncle who grows wheat or a worker's master who bake cakes. This simple "buy cake" scenario can be expressed in about.

Figure 1. Cake Production Division

Figure 1 illustrates how a cake arrives at a customer. As you can see, making a cake is not a single task and requires a lot of division of labor. If you look at it from the bottom up, the main division of labor includes: planting and production of basic material materials, raw material processing, cake processing, and commercial sales. Not all division of labor is shown in this way. The division of labor has some characteristics. The following is a summary.

1. The lower layer does not know the existence of the upper layer. For example, a dairy factory produces milk. It does not have to know what milk is taken for. It may be bought by a cream factory for cream, or it may be bought by an ice cream factory for ice cream, it may also be acquired to make milk sugar. In short, it just completes its own responsibility-to produce milk, and has no knowledge of its upper layer. Similarly, the cream processing factory only produces cream, and it does not have to know whether the cream is taken as a cake or Moka coffee.

2. Each layer only knows the next layer (except the last layer, because the last layer does not have the next layer), but does not know the other lower layer. For example, a cake factory only needs to know how to extract flour, cream, and eggs from a flour mill, cream mill, and Egg Factory, you don't have to worry about how the flour and the cream come from.

It can be said that the division of labor in line with the above two points is the ideological source of the layered architecture. The following is a little more formal. The so-called stratified thinking is such a division of labor: it organizes the system according to different responsibilities into an orderly level. In addition to the top layer, each layer only provides several services for its adjacent upper layer, but does not know the existence of the upper layer. In addition to the bottom layer, each layer only calls services near the lower layer.

Therefore, the so-called "stratified thinking" is just a special form of division of labor. The layered concept in computer software architecture is a special case of applying this idea to software development, while the "Dal + BLL + PL" approach adopted by petshop is, it is just a special case of applying this idea to software development. For example, if the business of a system is very simple, just adding, deleting, modifying, and querying, then BLL will not work, and the "Dal + PL" approach will be well completed, which is also a good Hierarchical architecture. Another example is that if the business of a system is complex, you need to normalize the system, perform operations, and then sort it out, the "Dal + normalization layer + computing layer + arrangement layer + PL" layer architecture is also reasonable. If the interface exposed by a system BLL is too complicated, it is normal to add a "Facade service layer" between BLL and PL in the facade mode. Furthermore, if a system does not require data access, such as a calculator program, we just want to separate the representation from the business (computing function), then there will be no Dal, "BLL + PL" is reasonable. Therefore, the essence of a layered architecture is to "organize the system into an orderly hierarchy according to different responsibilities ......" This paragraph describes, rather than simply "dividing the system into Dal + BLL + PL", rather than "architecture by petshop ".

The following is an excerpt from Fowler's definition of hierarchy in patterns of enterprise application architecture:

When thinking of a system in terms of layers, you imagine the principal subsystem in the software arranged in some form of layer cake, where each layer rests on lower layer. in this scheme the higher layer uses various services defined by lower layer, but lower layer is unaware of the higher layer. furthemore, each layer usally hides its lower layers from the layers above.

-- Martin Fowler, patterns of enterprise application architecture, P17

The general translation is as follows:

When we say a system is a layered architecture, you can think of this software as a cake with many layers, each of which is placed on its next layer. The higher layer uses many lower-layer definitions and services, but the lower layer does not notice the existence of the higher layer. In addition, each layer hides a lower layer from its upper layer.

-- Martin Fuller, enterprise application architecture model, P17

However, one thing to declare here: Although "Dal + BLL + PL" is not equivalent to a layered architecture, it is just an instance. But at the same time, we need to clearly understand that this method is so popular that Microsoft's official examples are structured like this because for many systems, especially large and medium-sized MIS systems, this architecture should be prioritized. In this section, I have never criticized "Dal + BLL + PL". On the contrary, when developing a system, this approach can be prioritized, then we can make some improvements based on the characteristics of the system. What I have stressed in this section is that we cannot regard "Dal + BLL + PL" as the essence of a layered architecture, nor can we equate it with the concept of "layered architecture.

Advantages and disadvantages of Layered Architecture

On the basis of understanding the nature of the layered architecture, we can confidently analyze the advantages and disadvantages of the layered architecture. Let's talk little about it. In this section, we will go straight into the topic.

The advantages of layered architecture are as follows:

1. Remove developers' attention. Since a layer only calls the services provided by its adjacent next layer, as long as the APIS at the current layer and the APIS at the next layer are completely defined, when developing a layer, developers can focus on the ideas, models, and technologies used in this layer. This is equivalent to introducing the productivity improvement advantage brought by the division of labor into software development. Another example is buying a cake. As a supermarket, you only need to know the underlying API (how to obtain the cake from the cake factory) and the API that needs to be implemented on the current layer (sell the cake to the customer ), you don't have to worry about how to grow wheat, how to grind flour, how to make cream, and how to make cakes. In this way, supermarkets only need to carry out commercial operations, rather than industrial operations, so specific, will inevitably improve the business level.

2. lossless replacement. Imagine if a dairy farm goes down, will the cream processing factory go down? Of course not. It can quickly replace a dairy farm, because each dairy farm can provide the "milk" service. For another example, if one day the country has introduced a policy that requires all cream plants to import raw materials from qualified dairy farms, and the partner milk suppliers of a cream factory fail to pass the review, you only need to change the cooperation that has passed the review. In addition, the various links inside the cream factory do not need to change, because different dairy farms can provide the "milk supply" service. If the cream factory raises its own cattle to produce milk, once this policy is met, it will have to go to the relevant departments for review, adjust the corresponding business process, and take a long time. The same principle in the program is most often heard of as database migration.

3. Reduced inter-system dependencies. In the example of cake, if the machine is changed in the cake factory one day or the business process is adjusted, do customers need to care? Obviously, this is not necessary because the customer only calls the services provided by supermarkets. Supermarkets hide all the following industry details for customers. If every customer buys the same product, they need to know a series of details from raw material production to molding and then to sales. In another program, the presentation layer only calls services at the business layer. How many layers are there under the business layer? How does data come from? How to save it? Is it true or fabricated? Do not need to understand, which greatly reduces the dependencies between the various responsibilities of the system.

4. reuse. For example, you can go to this supermarket to buy things, or I can go to this supermarket to buy things. The cake factory can extract flour from the flour mill, or from the steamed bread factory. In this way, the same layer can provide services for different upper layers, achieving the purpose of reuse. Specific to the program, for example, the Meteorological Bureau produced and released a "service layer" to provide weather forecast information. In this way, websites such as Sina and Sohu can use the services provided by this service layer to create a weather forecast page. QQ can also use this service to add weather forecasts on its chat tools, you need to use the weather forecast function or call the service layer of the meteorological station ".

Let's talk about the advantages and disadvantages of the layered architecture:

1. Cascade modification problems. This problem is not a metaphor in reality, but I believe many friends in the program understand it. For example, in a human affairs management system, the personnel information can only be viewed by page. Now, you need to add a function that can be divided by department at the same time. For example, you can view "the first 50 people in the Sales Department", so that all layers of this function need to be modified.

2. Performance problems. Operations that were originally directly transferred are now transferred at different layers, which will inevitably lead to a decline in performance. For example, in the example of buying a cake. When customers enjoy the benefits of division of labor, they also need to bear the rise in cake prices caused by the distribution of departments on different layers. This is because the cost is increased by layering, such as transportation, coordination and management costs between different layers of departments.

Looking at the above analysis, the layered architecture has advantages and disadvantages. This must be because everything in the world has both advantages and disadvantages. Therefore, it is unwise and unscientific to take the "layered architecture" and "one stick to death" approach. To treat a layered architecture, we should clarify its nature and advantages and disadvantages, and then make rational analysis and choices based on the specific situation.

From the above analysis, we can see that the layered architecture can reduce the cost of changes in the layer, and is very sensitive to API changes. As mentioned in cascade modifications, the new requirement of "dividing departments while paging" is the API change. API changes are fatal to the layered architecture and are difficult to modify. Therefore, a simple judgment rule is: If frequent changes (or even whole-layer replacement) in your system layer are likely, and the API changes are unlikely, layers are used; if the API may change frequently, you need to use the layered architecture with caution.

Next

In fact, the main content I want to talk about is the first three sections. But there are still some things that I want to be nagging.

This article is not a technical article, so I will not mention technical details, but I just want to help you clarify your misunderstanding of layering. Recently I have read a lot of discussions about layered architecture (or L3 Architecture). Most of them are critical, and some even think that layered architecture is useless. I think the people who come up with this idea have roughly gone through the following stages: I have heard about layering, rough learning layering, imitating and using layering, being very uncomfortable, and criticizing.

In fact, any technology is objective and there is no error. The mistake lies in the fact that people are not using it correctly, or they are not using it properly. Just like we can't criticize that blades are not suitable for cutting forks, and we can't criticize that firewood knives are not suitable for shaving. If a technology wants to exert its power, the key must be to use it correctly. To use it correctly, we need to have a deep foundation, and we need to study hard and be diligent in thinking. This is not an overnight task. We must have persistent perseverance. We should strive to be a good man who is good at studying and grasping the essence of things, instead of a man who splits firewood with a blade and shave his beard with a knife, and then scolds the blades and knives as garbage.

The concept of hierarchy has never been first proposed in the software architecture. The networks we use on the Internet every day follow the OSI Layer 7 protocol. The design of the network structure is a model for the rational application of the concept of hierarchy. In addition, in many other engineering technology fields, stratified thinking is also common. Therefore, we should not regard hierarchy as the unique capabilities of computer people or even software developers. The technology that applies hierarchy to software architecture in those fields is still immature, and there are still many things waiting for us to do.

Finally, I strongly recommend a book called patterns of enterprise application architecture by Martin Fowler. I believe that after reading this book, we will greatly improve our understanding of the concept of hierarchy and the application and decision-making of specific models in hierarchy. You will understand that the original layering is not only "Dal", "BLL", but also how many internal things are there.

Wish everyone a happy 6th! :)