The layered software architecture pattern is the most commonly used architecture pattern in software engineering. This architectural pattern is also known as the n-tier architecture style or the multi-layered architecture style. The purpose of a layered architecture is to organize the components of an application into horizontal logical layers and physical tiers.
A layer is a logical unit that separates a specific role and responsibility within an application. Each layer manages its own software dependencies. A higher layer can use services in a lower layer, but not the other way around. A tier is a physical unit where the code runs; for example, a web server or a database.
Each layer can be hosted in its own tier, however it is not required. Several layers can be hosted on the same tier. Scalability, maintainability and resiliency are increased when physically separating the tiers, however latency increases due to the additional network communication.
A traditional layered software architecture has three tiers and four layers. Consider the below architectural diagram.
The four standard layers are described as follows.
- Presentation Layer
This layer contains all user interfaces exposed to a user. It may provide different types of user interfaces, namely web, desktop and native mobile applications.
- Business Logic Layer
This layer handles all business logic, validations and business processes.
- Data Access Layer
This layer is responsible for interacting with a database. It is also known as the persistence layer.
- Data Store Layer
This layer is the actual data store for the application.
By introducing different layers for the software components, separation of concerns (SoC) is increased drastically, thus improving simplicity, maintainability and test-ability of the components.
The tiers are described as follows.
- Tier 1: The Presentation Tier
This tier hosts the front-end code base, that is, the presentation layer. This is the topmost level of the application and it is essentially a layer users can access directly.
- Tier 2: The Application Tier
This tier hosts the back-end code base, that is, the business logic layer and data access layer. It is also known as the middle tier.
- Tier 3: The Data Tier
This tier hosts the data store, that is, the data store layer. Databases, file system, blob storage, document database, etc are examples of resources found in a data store.
There are two ways to implement a layered software architecture, namely closed layered architecture and opened layered architecture.
Closed Layered Architecture
In a closed layered architecture, a layer can only call the next layer immediately below it. Consider the below closed layered architecture diagram.
In the above architecture diagram, each layer is marked as closed. This means that in order for a request to progress to the bottom most layer, the request will need to flow through each layer. For example, when a request is initiated via the presentation layer, the request will first go through the business logic layer, next to the data access layer and finally to the data store layer.
The purpose of the closed layered architecture is to ensure that layers are completely isolated from one another, meaning that changes made in one layer of the architecture does not impact other layers. In other words, layers are loosely coupled, where each layer has little to no knowledge of other layers.
Note that when implementing a closed layered architecture, this limits the dependencies between layers, thus introducing unnecessary network traffic, since one layer simply passes requests along to the next layer.
Opened Layered Architecture
In an opened layered architecture, a layer can call any layer below it, provided the layer below it is marked as opened. Consider the below opened layered architecture diagram.
In the above diagram, a new services layer was introduced. This layer provides a number of service components. Not all service components in the services layer interact with a database. For this reason, the layer is marked as opened. This means that the business logic layer has access to both the services layer and data access layer, that is, the business logic layer does not need to go through the services layer in order to use the data access layer.
Architecture sinkhole anti-pattern
A most common problem with the layered software architecture is when requests flow through multiple layers of the architecture as simple pass-through requests with no logic performed within each layer. This is known as the architecture sinkhole anti-pattern. Mark Richards suggests to utilize the 80-20 rule to determine if this anti-pattern is a problem.
Every layered architecture will have at least some scenarios that fall into the architecture sinkhole anti-pattern. The key, however, is to analyze the percentage of requests that fall into this category. The 80-20 rule is usually a good practice to follow to determine whether or not you are experiencing the architecture sinkhole anti-pattern.
Mark Richards
Summary
The layered architecture pattern is a very simple, structured and solid pattern that is well known in enterprise software. This pattern is also portable between cloud and on-premise platforms.
There are a number of architectural patterns available, each with its own pros and cons. Choosing an architectural pattern depends on the scenario or project requirements.
Further information on the layered architecture pattern in software engineering can be found at the following links: