It is an architectural pattern that organises codebase into horizontal layers that are separated from each other. Each layer has a specific role and responsibility within the application to satisfy a particular business request.
Layers
In layered architecture, there are usually four layers.
Presentation Layer
This layer is responsible for handling UI and browser communication. Most of the time, it will be a user interface or CLI tool that the end user will use to communicate with your service, will use forms etc.
Business Layer
This layer is responsible for executing business logic associated with the request. It will contain core rules and business processes. It also defines how the data can be created, modified or deleted based on the business rules.
Persistance Layer
This layer is like a helper that helps to retrieve and store data in a database layer. It usually will be an ORM or some other tool, that helps your business layer to co communicate with a database. As part of this layer, the following may be included:
- caching
- transactions
- connection management
Essentially, it may be anything that is responsible for storage systems
Database layer
It is a layer where all data is stored, it may be in an SQL database or NoSQL Databases database. This layer’s responsibility is only to care about the storage of data, nothing more and nothing less.
Layers are closed
Every layer within layered architecture is closed. This means that a layers shouldn’t care about how other layers are working and should only care about their responsibility. This promotes a separation of concern.
Communication between layers
Communication between layers is layered; this means that layers cannot skip other layers, and the communication has to go from or to the layer above or below it.
Pros of using Layered Architecture
Easy of development
Layered architecture is quite common and most developers should be familiar with it. It is the easiest to grasp and understand.
Separation of concerns
Because all layers are closed, it makes the whole system easy to test. It also helps to reuse across the application or even projects.
Cons of using Layered Architecture
Scalability
Layered architecture doesn’t scale very well in large organisations, especially the ones where there’s lots of changes happening. It definitely won’t work in organisations, where distributed systems or microservices are created and broken down into smaller, independent units.
Tightly coupled (if not done right)
When layered architecture is not done right (components are not truly separated from each other), it will make it difficult to deploy, because they will have to be coordinated, and deployed in a certain order.
Agility
Layered architecture doesn’t work in environments, where things are constantly changing. A change in one layer may affect other layers and they will have to be updated as well.