Architecture Styles: Layered Architecture


Layered architecture is also known as n-tiered architecture, is a monolithic general-purpose kind of architecture in which its layers are partitioned according to their technical responsibilities. One example of the layers in this architecture would be the Presentation layer, Business layer, Persistence layer, and database layer. Each one of these layers represents a technical role in the architecture. Layered architecture is a database-centric architecture, and developers start by building the database first then they implement the other layers.

Despite there is no limited number of layers that can exist in such architecture, there are four frequent layers:

Layers physical separation

There are three main kinds of physical separation of the layers of this architecture:

  1. The most common is separating the database layer from the rest of the layers. And that means you physically deploy your database layer separately from other layers.

  2. The second is to separate into the presentation layer, database layer, and the rest of your application.

  3. The last one is keeping all layers in one physical unit. And this is very useful when building a small application. Even the database is not separated from the rest of the layers, like when using in-memory databases or file systems.

Layers communication

The standard communication pattern between the layers is top to bottom, which means a connection from the presentation layer must go through the business layer before it goes to the persistence layer. Within the communication point of view, layers can be of two types:

An example of all closed layers:

The connection can only go through the next layer and must not bypass it. So presentation layer cannot access the database directly without accessing the business layer. And that is excellent isolation of layers, which means that one change in any layer cannot affect other layers while their public contract remains unchanged.

Another variant of this would have some open layers. These are optional layers like logging, auditing, and formatting that might have logic that is common between all business layer components. Then it will make sense to mark these layers as open.

Usage: When to use such style?

This architecture style is so simple and easy to start with. All software engineers levels can easily understand it. Also, it is straightforward to maintain at the beginning, given its monolithic nature.

So use this architecture if:


Final words

Always use the architecture that makes sense to your current situation. There is nothing like “the best architecture.” Every different position requires another solution. And keep in mind that you might migrate from one architecture to another, so maintain a minimum level of reuse and inheritance in addition to a high level of modularity