Software Architecture Patterns
Layered Architecture
Layered Architecture is the most common architecture pattern, also known as the n-tier architecture pattern. This is the de facto standard for most JAVA EE applications. And also widely known by most architects, developers, and designers. The layered architecture pattern is the traditional method for designing software, which has been mostly the preferred choice for most companies.
Description
The components within the layered architecture pattern are organized into horizontal layers, each layer has a specific responsibility to perform within the application. As shown in Figure 1, it contains four different layers — presentation, business, persistence, and database.
Presentation Layer — It is responsible for handling all user interface and browser communication logic.
Business Layer — It is responsible for executing specific business rules associated with the request.
Persistence Layer — It is responsible for persisting the data in the database. In other words, it presents persistent data in the application which includes the DAO (Data Access Object) presentation, ORM (Object Relational Mappings), and other modes of presentation.
Database Layer — It is responsible for managing the persistent data and supplies that to the other layers.
One of the powerful features of the layered architecture pattern is the separation of concerns among components. For example, the presentation layer doesn’t need to know about how to get customer data; since its business is focused on displaying that information to the end-users. In the same way, the business layer is concerned with getting the data from the persistence layer and performing some business logic against those data if required, and passing that information to the presentation layer but it doesn’t have to worry about how to format the customer data for display on a screen. In this way, components within a specific layer have to deal only with logic that pertains to that layer.
Key Concept: Closed Layers
As shown in Figure 2, a request moves from layer to next layer respectively in a top to bottom approach. Each layer in this architecture is marked as being closed. This is a very important concept in the layered architecture pattern where a closed layer means that as a request flows from one layer to another, it must go through the layer right below to reach the next layer and it follows this pattern all the way to the bottom.
Why not allow the presentation layer direct access to either the persistence layer or database layer?
Layers of isolation — it is a key concept which promotes the ideology that the changes made in one layer of the architecture generally shouldn’t impact or affect components in other layers.
Key Concept: Open Layers
As Figure 3 illustrates, the services layer is marked as open, which means the request is allowed to bypass this open layer and go directly to the layer below it if required. Sometimes, it is required to add a shared-services layer to an architecture containing common service components accessed by components within the business layer and which helps to restrict the access to the shared services to the business layer and not to the presentation layer.
Understanding the concept of open and closed layers most likely helps in defining the relationship between architecture layers and request flows within the application. It is really essential to document which layers in the architecture are open and closed since it is the essence of this architecture pattern.
Layered Architecture: Example
As shown in Figure 4, the black arrow represents the request flowing down to the database and the red arrows show the response flowing back up to the user. Let us categorize the actions on the basis of the different layers.
Presentation Layer —The customer screen is responsible for handling the request and displaying the information. It has no concerns about how the data is being retrieved. The customer delegate module is responsible for contacting the concerned module in the business layer and passing the request for further processing.
Business Layer —The customer object is responsible for aggregating all of the information needed by the business request. This module calls the respected module in the persistence layer to get the relevant information.
Persistence Layer — The customer dao and the order dao modules are responsible for executing query statements to retrieve the corresponding data and pass it back up to the customer object in the business layer.
Database Layer — The layer where the persistence layer executes its query to retrieve data from.
Pattern Analysis
The layered architecture pattern is mostly a good starting point for most applications, especially when one does not know the best-suited pattern. But still one should always watch out for architecture sinkhole anti-pattern. This anti-pattern describes the situation where requests flow from one layer to another without performing any logic whatsoever and only flow just to reach the database layer to get some data and the data is then passed all the way back up without any additional processing.
It is pretty common that every layered architecture will come across an architecture sinkhole anti-pattern but the key to balance is the 80–20 rule to make sure that one is not facing this anti-pattern.
Agility — Low; It is still time-consuming to make changes in this architecture pattern because of the monolithic nature of most implementations.
Ease of deployment — Low; This pattern does not easily lend itself toward a continuous delivery pipeline.
Testability — High; Since components belong to their specific layers, other layers can be mocked which makes this pattern relatively easy to test.
Performace — Low; It could be low due to having the communication overhead.
Scalability — Low; It is generally difficult to scale due to its monolithic implementation nature.
Ease of development — High; It is a very much well-known pattern and is not too complicated to implement.
References
- Software Architecture Patterns by Mark Richards
