This software architecture divides your application into layers — independent parts of the system that each have their own distinct and specific responsibilities. Typically, each layer is “closed”, which means they only interact with its adjacent layers. While there exist architectures with just one and two layers, we will focus on those with three or more layers — also known as the n-tier architecture.
A typical multilayered architecture will have the following structure and contain the following layers:
Advantages
- Layers are independent: Changes in one layer does not affect the others, so each layer can be modified without potentially harmful side effects in the application
- Scalability: Each layer can be run in a different server
- Organisation: Good separation of concerns because each layer performs a distinct and separate function
Disadvantages
- Performance & maintainability: For small applications, this architecture is overkill because the many layers can create performance issues
Real-World Example
Let’s take an online banking website to illustrate this architecture. Online banking allows a user to conduct financial transactions via the Internet, at home instead of at a physical bank. This system is usually connected to the bank’s core system.
Online banking applications are usually organised in layers. This is such that one layer can be changed without affecting other layers, hence functionality can be added/modified whilst minimising impact to existing users and crucial banking services.
In the presentation layer, the user of the online banking system can perform many actions on the website’s interface. This includes, but is not limited to, filling in forms to sign in with their bank ID and password, pressing menus to navigate the site in order to perform some other actions, and clicking buttons to confirm a transfer of money out of their account. These user actions in the presentation layer are then passed down to the application layer.
The application layer contains important logic. Based on the user actions received, it processes them and passes the appropriate commands on to the business layer.
The business layer then reconciles the actions with the business rules that are defined in the business processes for the online banking system. A business rule defines or constrains some aspect of business. For example, if the user requests for a personal financial statement, the system will email it to the user. If the user attempts to transfer an amount exceeding the stipulated limit, the system must reject the attempt. For all user requests that do not violate any business rules, they will be passed to the persistence layer.
The persistence layer processes the requests received and contains the logic that determines how the data should change in the database. For example, if user A transfers $10 to user B, the persistence layer will trigger a deduction in user A’s total amount of money that is recorded in the database, and trigger an addition in user B’s total amount of money that is recorded in the database. Data in the database layer is hence changed based on the persistence layer’s logic.
Conclusion
A multilayered architecture is best suited for large applications, in order to increase the organisation and maintainability of the different parts of the application.
