Multi-layer / Multi-tier architectural pattern

In the past, I had been working on applications that were multi-layered / multi-tier applications. However, I had not recognized the terminologies as well as the subtle differences between multi-layered and multi-tier architectures and some of the pitfalls one may want to watch out for when implementing the pattern.

Multi-layer architecture

Below is an example of the layers in a web application :

For the purpose of discussion, let’s pretend we have a fictitious Educator Tools application which is designed to help principals with managing high school students.

• The Presentation layer represents the graphical user interface for the user to interact with the application. For example, in the Educator Tools application , we may have a button which upon clicking, talks to the controller layer to retrieve a transcript of a student and displays to the user.
• The Controller layer exposes the backend API via HTTP endpoints. A HTTP endpoint allows a client to retrieve data or perform an action against a resource via HTTP. Usually, the controller performs validations on the input and orchestrates the steps to fulfil the request, but the real work happens at the layers below the controller.
• The business logic layer defines and implements business rules. For example, the Educator Tools application has a feature that can let a user know whether a high school student can graduate. The student can graduate provided he has passed all the courses, took the high school exit exam and paid the school’s fees. The rules to determine whether the student can graduate may reside in a class at the service layer. To further provide separation of concerns and decoupling, the service often delegate the tasks of retrieving data from storages to the persistence layer.
• The persistence layer contains logics of retrieving and storing data from and to storages such as database, files, and cloud storages etc … and mapping the data into domain objects.

The above diagram is just an example of layers in an application. In practice, an enterprise application may have more or less layers. For example, in simple applications may have both the business and persistence logic at a same layer. On the other hand, complex applications may have separate persistence layers for different types of data or storages.

Closed vs open layer architecture

In the above diagram, the arrows point downward to signify that a layer only depend on another layer which is immediately below it. This type of layered architecture is known as closed layer architecture. If done right, a closed layer architecture reduces couplings in an application. For example, suppose in the Educator Tools application, we want to switch the ORM framework from Entity Framework to Dapper. In a closed layered architecture, we only need to update the service layer which is the next closet layer above the infrastructure layer. We should not have to update the controller or the presentation layer because they don’t depend on the persistence layer.

Sometimes, it’s necessary for a layer to call classes at another layer that is not immediately below it. For example, in the Educator Tools application, beneath the persistence layer, we can have a common layer which contains helper functions, static and domain classes, constants etc … for sharing throughout the application. Both the service and the controller layers may need to access classes at the common layer without going through the persistence layer. This type of architecture is known as open layer architecture.

Multi-tier architecture

Just as multi-layer architecture separates an application into logical layers, multi-tier architecture separates an application into physical tiers. For example, in the Educator Tools application, the persistence layer may reside in a server that is separate from where the business and controller layers reside, and the presentation layer resides yet in a separate tier such as the browsers. A more complex application could have more tiers.

The Architecture sinkhole anti-pattern

A multi-layer application may have an anti-pattern in which a layer acting mostly as a pass-through layer allowing requests to go the layer immediately below it, without doing any processing. This anti-pattern is known as the Architecture sinkhole anti-pattern. For awhile, I had seen but not recognized this anti-pattern. For example, an application with this antipattern may have classes at the business layer which do nothing except forward the requests to the persistence layer to do some CRUD operations. In the book Software Architecture Patterns, the author suggests using the 20-80 rule to determine if your application has the architecture sinkhole antipattern and if so to consider opening up some of the layers.

It is typical to have around 20 percent of the requests as simple pass-through processing and 80 percent of the requests having some business logic associated with the request. However, if you find that this ratio is reversed and a majority of your requests are simple pass-through processing, you might want to consider making some of the architecture layers open, keeping in mind that it will be more difficult to control change due to the lack of layer isolation. 

Chapter 1 – Layered Architecture in Software Architecture Patterns by Mark Richards

References

N-tier architecture style

Service Layer

Multitier architecture

Software Architecture Patterns

Layers in DDD microservices