Layered Pattern
Overview
The layered architecture pattern, often known as the n-tier architecture pattern, is the most frequent architecture pattern. Because this pattern is the de facto norm for most Java EE applications, most architects, designers, and developers are familiar with it. The layered architecture pattern closely resembles the traditional IT communication and organisational structures present in most businesses, making it an obvious choice for the majority of business application development efforts.
Introduction to Layered Pattern
Layered architectures are widely used in software development and are considered to be the most prevalent and commonly utilised architectural framework. It is an architectural pattern made up of numerous independent horizontal layers that work together to form a single software unit. This pattern is also known as an n-tier architecture. A layer is a logical division of parts or programme code. This architecture typically places related or comparable components on the same tiers. Every layer is unique and affects a different aspect of the entire system.
Pattern Description
-
Within the application, each layer of the layered architecture pattern is responsible for a particular task. For instance, the user interface and browser communication logic would be handled by the presentation layer, whilst the business layer would be in charge of carrying out the specific business rules related to the request.
-
Each layer of the architecture creates an abstraction around the work required to complete a specific business requirement. For instance, the presentation layer just needs to display customer data on a screen in a specific way; it is not required to understand or worry about how to obtain customer data. The business layer only needs to obtain the data from the persistence layer, apply business logic to the data (e.g., calculate values or aggregate data), and then pass that information up to the presentation layer. In a similar manner, the business layer need not worry about how to format customer data for display on a screen or even where the customer data is coming from.
-
-
Separating concerns among components is one of the layered architecture pattern's strong points. Components inside that layer deal with only logic specific to a certain layer. For instance, the presentation layer's components only deal with presentation logic, whereas the business layer's components only deal with business logic. Due to the clearly defined component interfaces and constrained component scope, this type of component classification makes it simple to incorporate efficient roles and responsibility models into your architecture. It also makes it simple to develop, test, govern, and maintain applications using this architecture pattern.
The Standard Layers
The layered architecture pattern organises components into horizontal layers, with each layer playing a specific function inside the application (e.g., presentation logic or business logic). The presentation, business, persistence, and database layers are the most common layers in layered architectures. However, the layered architecture pattern does not specify the number or types of layers that must be present in the design.
Presentation Layer
This layer houses the front-end code base. This is the application's highest level and effectively, a layer that users can access directly. All interfaces that are visible to users are contained in this layer. It might offer many user interfaces, including online, desktop, and native mobile apps.
Business Layer
This layer handles all business operations, validations, and logic. It deals with issues pertaining to fulfilling functional requirements. The application's behaviour is governed by rules in this document, such as "If an invoice is printed, send an email to the customer, select all sold products, and reduce their stock in the stock management module."
Persistence Layer
This layer is in charge of communicating with a database. It is employed to manage operations like object-relational mapping. By updating the changes in the databases, it is making those changes 'persist'.
Database Layer
All the application's data is stored at this layer. It deals with things like which database tables must be queried to retrieve the required data.
Considerations
Architecture Sinkhole
The first thing to look out for is the anti-pattern known as the architecture sinkhole. This anti-pattern describes a scenario where requests are processed simply as pass-through data via various layers of the architecture, with little to no logic being applied to each tier. Assume, for instance, that the presentation layer responds to a user request to retrieve customer information. The business layer simply forwards the request from the display layer to the persistence layer, which then makes a straightforward SQL call to the database layer to obtain the customer data. Without any further processing or logic to aggregate, compute, or transform the data, the information is then transmitted all the way back up the stack. A possible solution is to analyse the percentage of requests that fall into this category and try to limit them.
Leaning towards Monoliths
Another thing to keep in mind about the layered architecture pattern is that it leans towards the monolithic style, even if the presentation and business layers are separated into deployable components. This might not be a problem for some applications, but it does raise some potential issues with deployment, general resilience and dependability, performance, and scalability.
Pattern Analysis
The table below offers a rating and analysis of the layered architecture pattern's common architectural traits. The grade for each attribute is based on the pattern's inherent predisposition for that characteristic as a capability, as well as what the pattern is widely recognised for.
| Attribute | Rating | Analysis |
|---|---|---|
| Ease of Development | high | This design pattern is well-known and doesn't require too much effort to implement. Moreover, since most businesses divide skill sets into layers (presentation, business, and database), this design becomes an obvious choice for most business-application development. |
| Ease of deployment | low | Because components relate to specific layers in the architecture, other layers can be mocked or stubbed, making this architecture relatively easy to test. |
| Performance | low | Applications built utilising this architecture pattern are typically challenging to grow due to the inclination toward tightly connected and monolithic implementations of this style. |
| Agility | low | Agility refers to the ability to adjust swiftly to a changing environment. While modification can be separated using the layers of isolation aspect of this pattern, making changes in this architecture pattern is still tedious and time-consuming due to the monolithic structure of most implementations and the close coupling of components typically found with this design. |
| Testability | high | Even if it's true that some layered designs can function effectively, the pattern does not work well for high-performance applications because it is inefficient to have to pass through several layers of the architecture in order to fulfil a customer's request. |
Advantages
- Since most applications naturally operate in layers, development is straightforward and simple.
- Since components belong to specific layers, testing is simple. They may therefore be tested independently.
- Because each layer's function is distinct from the other levels' functions, there are fewer dependencies.
Disadvantages
- Although changes to a specific layer can be made, it isn't easy because the programme is a single entity. Additionally, the interaction between layers often makes it more difficult. This makes scaling even more challenging.
- It must be deployed as a single unit, so changing one layer requires redeploying the entire system.
- It will perform worse as it grows since it needs more resources to process requests through numerous layers.
Conclusion
- The layered architecture pattern is a strong all-purpose pattern that works well for most applications, making it an excellent place to start when deciding which architecture pattern is appropriate for your application.
- Each layer of the architecture creates an abstraction around the work required to complete a specific requirement.
- Separating concerns among components is one of the layered architecture pattern's strong points. Components inside that layer deal with only logic specific to a certain layer.
- It may suffer from an anti-pattern called the architectural sinkhole pattern.
- This design pattern is well-known and doesn't require too much effort to implement. It is simple to develop, test, govern, and maintain applications using this architecture pattern.