Architecture Styles: Layered Architecture
If you want to learn more about all kind of architectures I can recommend one of the best books out there which is Fundamentals of Software Architecture It not only contains a full definition and examples of every architecture, but also it tells you the pros and cons, and when to use every one of them and when not to. This book is so good for preparation for job interviews and if you want to start your journey to be a software architect.
Definition
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:
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.
The second is to separate into the presentation layer, database layer, and the rest of your application.
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:
- Closed: The previous layer cannot bypass a layer with a “closed” label, and the request must go through it before it proceeds.
- Open: The previous layer can bypass the layer with the “open” label.
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:
- You do not have teams with defined responsibilities
- You are just starting your business, and you have few resources
- You still do not know what your business structure is
- You are building a simple website or application with known and limited features
Disadvantages
- Even that we have closed/opened layers. Nothing prevents any layer from communicating with any other layer
- If you grow into multiple teams, it will be hard to do parallel work on your project
- With every tiny change, you have to redeploy the whole system, which is risky and takes an unreasonable amount of time
- Application takes a long time to start up
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
If you have any questions, suggestions, or you are seeking help, don't hesitate to get in touch with me on Twitter at @salem_hsn