---

Note

Many organizations in our lives work by some kind of hierarchy, a business, a government, a student society. Let's take a school for an example, the basic organization of people in a school could be visualized like this:

The boss of the school is the principal, who is the core of the school. The teachers are the next layer, while the students are the outermost layer. The students get information, support, and guidance from the teachers and grow into contributing members of society. In our example, they only interact with the teachers and not the principal.

The principal, in turn, supports the teachers. this could include providing a curriculum, dealing with a problem that the teachers cannot handle themselves, or giving feedback to the teachers.

In software applications, the inner layer in an interaction is usually providing services to the one outside it. Another common way to represent a layered structure is like this:

What we called the inner layers are now the bottom layers. These three groups are the three layers of the organization. People in adjacent layers interact so the students and the principal only have to interact with one layer, the teachers, while the teachers have to interact with both of their adjacent layers, the principal and the students. People in one layer can interact with another person in the same layer.

In software, this is often the case. A layer is a collection of components that work together towards a common purpose. If we add more layers, each layer would still communicate only with it's direct neighbors.

If we add a superintendent layer below the principal the principal would only need to interact with the superintendent and the teachers.

As far as the students are concerned, the superintendent is totally hidden. When an upper layer interacts with the layer directly below it, it cannot see the deeper layers, in regards to the school system, the principal could change the students would have no idea.

The inner/bottom layer usually provides services and/or abstractions for the layer outside/above it, For example, a higher layer may request information or operations from the layer below. And a layer below could signal an event for a layer above.

Layering allows for separation of concerns into each of the layers. Many layered systems are split into:

• Presentation
• Logic
• Data

Hardware systems, such as personal computers or communication protocols are usually based on layers of increased abstraction from the hardware itself.

The Operating System for a computer is a common example of a layered system.

Benefits of the layered structure include:

• Users can perform complex tasks without understanding the layers below, in the same way, programmers can create applications that rely on the libraries layer without needing direct knowledge of the kernel.

• Different layers can be run at different levels of authorization/privileges. The top layer is typically run in what is called the user space, which does not have the authority to allocate system resources or communicate with hardware directly. This so called sandboxing, improves security and reliability of the kernel.

• Your design will be more loosely coupled as architectures follow the principle of least knowledge.

Each layer only interacts directly with adjacent layers, Lower layers typically provide services to the layer above. So, if you do replace a layer, you only have to ensure that it's interface with the layer above is consistent with the previous implementation.

Unfortunately, not every software problem can easily be mapped to a layered architecture. Even in the simple example of a school, we know the students of a school do not just talk with the teachers. The principal may like to talk with the students directly to see how they are doing.

There are some questions asked for the school example:

• Where would administrative staff and/or parents go? Depending on their tasks, they can actually interact with any layer.

• What about a system for accessing/changing the marks of the students? All layers would need to access it.

This is not easily mapped to a strictly layered architecture, and that is even more true when you try to divide the software for a collection of object oriented software.

Enforcing layers also has an efficiency tradeoff, If you enforce the rule that only adjacent layers can communicate Any real system will have some interactions that are simply passed through one layer to the next.

Think back to the example of our teacher, maybe there is a math competition coming up that the principle wants to inform the students about. In a strictly layered system:

• The principle first tells the teachers to inform the students.

• The teachers then speak with the students. The notification passed through without modification.

From a software perspective, This extra communication adds complexity and uses processing resources. you have to balance this overhead against the separation of responsibilities gained from separating the layers.

If you find yourself passing most of your communication directly through a layer, then you should either relax the layer design or use a different architecture entirely. The layered architecture can be relaxed by allowing a pass through shown as a notch in the layer.

This shows that the principle sometimes interacts directly with the students. However, this makes for a tighter coupling in your software. The benefits of being convenient should be measured against the downsides, tighter coupling and a more complex structure.

More complex layered architectures can even use three dimensions, still with direct interactions only with adjacent layers.

In summary, layered architecture:

• It can be intuitive and powerful. Many organizations and solutions have layered structures, so it is easy to apply layered architecture where appropriate.

• It supports the separation of concerns, because each layer is a set of components with similar responsibility or purpose.

• It is modular and loosely coupled, as each layer only communications with one or two other layers, allowing for different implementations to be easily swapped.

• It can be adapted so that layering is not always strict, which helps manage design complexity or provide a starting point for structuring the system.