When we think about monolithic architecture patterns, layered architecture is what comes to mind first.
Layered Architectures are n-tier patterns is one of the most common architecture patterns. This style of architecture is the de facto standard for most applications, primarily because of its simplicity, familiarity, and low cost. If an engineer or architect is unsure which architecture style they are using chances is good that it is the layered architecture style they are implementing.
Topology
Components within the layered architecture style are organized into logical horizontal layers, with each layer performing a specific role within the application (such as presentation logic or business logic). Although there are no specific restrictions in terms of the number and types of layers that must exist, most layered architectures consist of four standard layers: presentation, business, persistence, and database.
Presentation Layer
This layer contains all categories related to the presentation layer, horizontally distributed.
Business Layer
This layer encapsulates business logic.
Persistence Layer
This layer encapsulates function level handling such as object-relationship handling.
Database Layer
This is where all the data is stored.
Variations
The above structure can be further broken into multiple logical choices
- In this first choice, the first three layers can be grouped into one application, and the database layer can be managed separately. Typical use cases include thick clients deployed on end-user machines and connectivity is established to backend databases (or file systems) for the applications.
- In the second choice, the first (Presentation) and last (Database) layers are physically separated whereas the second (Business) and the third (Persistence) are clubbed together. Typical use cases include applications where end-user applications are managed separately and again database (or file systems) are managed separately.
- In the third choice, all layers stay together and there is no physical separation between these components. This is common for on-prem applications and also the wherein in-memory database is used.
Layers of isolation
Each layer in the layered architecture style can be either closed or open. A closed layer means that as a request moves top-down from layer to layer, the request cannot skip any layers, but rather must go through the layer immediately below it to get to the next layer. For example, in a closed-layered architecture, a request originating from the presentation layer must first go through the business layer and then to the persistence layer before finally making it to the database layer.
If we look closely at these layers, sometimes it feels that it would be faster if in some cases, the Presentation layer can access the Database layer without traversing through the two additional layers, sometimes feel unnecessary layers.
So what is the better choice, closed layer, or open layer? The answer lies in the concept of layers of isolation.
The layers of isolation concept mean that changes made in one layer of the architecture generally does not impact components in other layers, providing the contracts between those layers remain unchanged. Each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture. However, to support layers of isolation, layers involved with the major flow of the request necessarily have to be closed.
If the presentation layer can directly access the database layer, then changes made to the database layer would impact both the business layer and the persistence layer, producing a very tightly coupled application with layer interdependencies between components. This type of architecture then becomes very delicate, as well as difficult and very expensive to change.
Why use this?
This pattern suits small, simple applications or small websites. Due to the nature of simplicity, this is a good starting point for developers and typically is the lowest cost architecture style.
Advantages
- Simple in nature
- Ease of testing
- Easy to implement
Disadvantages
- Based on the implementation, this could mean a singular unit, adding to the difficulties to de-couple
- Scalability is a challenge due to singular deployment
- Over a period of time, multiple layers get added to the overall architecture, leading to performance issues
Stay tuned to this blog series as we will be discussing how to apply the most common software architecture patterns. The next post of this series will discuss another interesting Architecture pattern.
If you have any queries/concerns, then you can drop me a message on LinkedIn.
Thanks for reading!
