Easy Guide to Multilayered Architecture

Traditional Layered architecture has 4 main parts (Layers ). 

1. Presentation Layer
2. Business Layer
3. Persistence Layer
4. Database Layer.

Number of layers may vary from application to application, and that is fine. But here we are saying that there 4 layers as a pattern.

Layers in this architecture are closed. That means is when going from top to bottom we can not skip any of the layers. To got to Business Layer you have to go though the Presentation Layer. To go to Persistence layer you have to go though Presentation and Business Layers.

You can see that those green arrows in the diagram points down. That means information/requests in the multilayered pattern always flow down. Persistence Layer would never make a call to the Business Layer. Business Layer is the one who makes calls to the Persistence Layer.

There is Separation of Concern in the layered architecture, which is an advantage. Each layer handles only one aspect of the application.

1. Presentation Layer : Contains parts only which is related to user interface.
2. Business Layer : Contains parts only which is related to business rules and business logic.
3. Persistence Layer : Contains parts only which is related to persistence.
4. Database Layer : Contains Databases/ files.

Layer isolation is another advantage of Layered architecture. This becomes a great abstraction patterns because of this layer isolation. If we need to change one of the layers in this pattern, we have the change that layer and may be the one above that, but not the other layers.
                               If we change the database in the Database Layer, then we might have to change the Persistence Layer since there might db specific queries in that layer. But here we don't need to change other layers. Business layer doesn't know what type of db we uses or what is the persistence framework we use. Business Layer doesn't need to know those details since it is connected to the Persistence Layer via abstract interfaces. Persistence Layer is isolated from the Business Layer by its Abstract interface and it can use any of the Persistence frameworks. This is common to the the other layers as well.

Variations

What if we have shared services? Where do we put those?

If we need to use a shared service, we can have it in this architecture. Since this is a shared service, we don't always call those services. Some times we do and some times we don't. That is why we have open layers in the multilayered architecture. We can skip the open layers or go though it.

This can be called a Open Layered Architecture. But that doesn't mean every layer is opened because we won't be able to gain anything useful in a layered architecture where every layer in open. 

Why is it Good?

1. Good general purpose Architecture. Most of the architects starts with this pattern.
2. Easy to implement, test and govern. Most developers are familiar with this pattern.
3. Good starting point for the most systems. Later you might be able to find out this is not the right one and move on to another one. But as a start, this pattern is good.

Why can't we use this for every system?

Let's take a J2EE application as an example. When starting from database and going up, we can find a JDBC driver. On top that there will be a framework which access jdbc driver via an API. On top of the framework there will be a persistence manager which abstract the framework. We got 4 levels of abstractions in the Persistence Layer.

We have to pass-though all those abstractions just because the pattern dictates that. That would be a indication that we are using the incorrect architecture pattern. 

Some might say, so why can't we use this pattern for every system. And that is not correct.

If we take a Trading application as the example, we won't be able get the performance and the scalability that we expect from this pattern.

Conslution

Multilayered Architecture is a good pattern and as we have mentioned earlier, it has good qualities. But when selecting a pattern what we should do before everything else is to understand what we the system should do, Rather than blindly selecting a pattern or a approach.

If the problem we have in hand is not shaped for the pattern we have selected, we will end up doing all sorts of wrong things in the project.

SHARE

Harsha Jayamanna