If you need to learn about N-Tier or Layered Architecture, you can find an ample of resources through google. So i am not expecting to repeat the same traditional approach here. The purpose of this article is to simply discuss the each layer/tier of N-Tier architecture with their purposes.
The most common architecture pattern is the layered architecture pattern. This is also known as the n-tier architecture pattern.
Components within the layered architecture pattern are organized into horizontal layers, each layer performing a specific role within the application (e.g., presentation logic or business logic). Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architectures consist of four standard layers:
- Presentation layer (known as view layer)
- Application layer (known as controller layer)
- Domain layer (known as service layer)
- Persistence layer (known as DAO layer)
The smaller applications may have only three layers, whereas larger and more complex business applications may contain five or more layers.Each layer of the layered architecture pattern has a specific role and responsibility within the application.
For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request.
One of the powerful features of the layered architecture pattern is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer. For example, components in the presentation layer deal only with presentation logic, whereas components residing in the business layer deal only with business logic.
Lets look at what will be the responsibility of each layer and what will be containing inside that.
Presentation Layer
This is known as the presentation tier or view tier. This is the starting point of Layer where the end user interact with the application. This layer will contain the classes and components required to present/handle the UI (User interfaces) for the end users. typically JSP files, Filters, classes used to render UI components. In addition, this will have the components and classes to receive the user requests and sending responses back to the end users.
Application Layer
This is where the request validation and flow control will happen. When user requests for a particular business operation, it will application later before going to the service/domain layer. In application layer, it will validate the user request to verify whether the request contain the enough information to handle the requested business operation. if it contains the required information, then it will be directed to the relevant business service reside in the domain/service layer.Otherwise, you will be notified about invalidity of the request (for the requested operation) through the presentation layer. So this will be the layer where your application business logics are controlled. (it decides whether to invoke the relevant servicer or not). This layer will not contain any business logic or domain specific services and it contains only the flow control and request validation logics.
Domain Layer
This is commonly known as the service layer. This contains all the domain specific business logic including service classes for business services , domain entities (domain classes) so on…
Persistence Layer
This is known as database layer or DAO layer. This contains the classes and components required to handle database related operations. Simply this contains the Repository classes, DAO classes and other classes that contains data access logic (HQL/SQL statements). All the Database related operations should be handled within this layer.
What is the Layers of Isolation?
The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer (such as a persistence layer containing SQL). If you allow the presentation layer direct access to the persistence layer, then changes made to SQL within the persistence layer would impact both the business layer and the presentation layer, thereby producing a very tightly coupled application with lots of interdependencies between components. This type of architecture then becomes very hard and expensive to change.
The layers of isolation concept also means that each layer is independent of the other layers, thereby having little or no knowledge of the inner workings of other layers in the architecture. To understand the power and importance of this concept, consider a large refactor‐ ing effort to convert the presentation framework from JSP (Java Server Pages) to JSF (Java Server Faces). Assuming that the contracts (e.g., model) used between the presentation layer and the business layer remain the same, the business layer is not affected by the refactoring and remains completely independent of the type of user- interface framework used by the presentation layer.
Final Observation
“Layered Architecture gives us nothing apart from a guideline on how to organize the source code.”
Benefits of a Layered Architecture
- Simplicity – the concept is very easy to learn and visible in the project at first glance.
- Consistent across different projects – the layers and so the overall code organization is pretty much the same in every layered project.
- Guaranteed separation of concerns – just the concerns that have a layer and to the point that you stick to the rules of Layered Architecture, but it’s very easy with the code organization it implies.
Drawbacks of a Layered Architecture
- No built-in scalability – Client does not request the layers, but request features. when the project grows with number of features, you need to find a key to organizing it further by yourself. The principles of Layered Architecture won’t help you.
- Hidden use cases – you can’t really say what a project is doing by simply looking at the code organization. You need to at least read the class names and, unfortunately, sometimes even the implementation.
- Low cohesion and high coupling – classes that contribute to common scenarios and business concepts are far from each other because the project is organized around separating technical concerns.Therefore the cohesion is low. In addition, each layer is tightly depend on the other layer and this increases high coupling.
References :
https://dzone.com/articles/package-by-feature-is-demanded
http://www.oreilly.com/programming/free/software-architecture-patterns.csp
www.SpringBootDev.com 