Lucian-Paul Torje - Design Patterns and Best Practices in Java

We try to divide our code and implementation into different layers, and each layer will have a fixed responsibility. There is no fixed set of layering that can be applied to all the projects, so you may need to think about what kind of layering will work for the project in hand.

The following diagram shows a common layered architecture, which can be a good starting point when thinking about a typical web application:

The design has the following layers:

• Presentation layer
• Controller/web service layer
• Service layer
• Business layer
• Data access layer

The Presentation layer is the layer that holds your UI, that is, HTML/JavaScript/JSPs, and so on. This is the layer that the end user can directly interact with.

The Controller/web service layer is the entry point for a request from a third party. This request can come from the presentation layer (mostly) or from another service; for example, a mobile or desktop application. As this is the entry point for any request, this layer will apply to any initial level checks, data cleanups, validations, security requirements, such as authentication and authorization, and so on. Once this layer is satisfied, the request is accepted and processed.

The Service layer, also known as the applicationlayer, is responsible for providing different services, such as adding a record, sending emails, downloading a file, generating a report, and so on. In a small-scale application, we can merge the service layer with the web service layer, especially when we know that the service layer will only handle requests from the web. If the current service can be called from other services as well, it is better to keep the service separate from the web service or controller.

The Business layer holds all the business-related logic. For example, in an employee data management service, if the system is trying to promote an employee as manager, it is the responsibility of this layer to apply all the business checks, including whether the employee has relevant experience, whether they are already serving as a deputy manager, whether last year's appraisal rating matches with the required rules, and so on. Sometimes, if the application or service in question does not have a strong set of business rules, the business layer is merged with the application layer. On the other hand, you may want to further divide the business layer into sublayers in case your application demands strong implementation of business rules. Again, there is no fixed set of guidelines that you need to follow while implementing a layered design, and the implementation can change based on your application or service needs.

The Data access layer is the layer responsible for managing all data-related operations, such as fetching data, representing data in the required format, cleaning data, storing data, updating data, and so on. While creating this layer, we can use an object relational mapping (ORM) framework or create our own handlers. The idea here is to keep other layers free from worrying about data handling, that is, how data is being stored. Is it coming from another third-party service or being stored locally? These and similar concerns are the responsibility of this layer only.

Cross-cutting concerns are the concerns that each layer needs to handle; for example, each layer is responsible for checking whether the request is coming from the proper channel and no unauthorized request gets served. Each layer may want to record the entry and exit of a request by logging each message. These concerns can be handled through common utilities that are used and spread across the layers or can be handled by each layer independently. It is usually a good idea to keep these concerns independent of core business or application logic, using techniques such as aspects-oriented programming (AOP).