Layered Architecture
When you develop a web application do you ever wonder about the architecture of the solution? Which architecture do you usually use? Why that one especially? What are its pros and cons and is it a good architecture for the problem your application is trying to solve?
Since my first web application projects on college until this very day I almost always worked on a 3-Layered Architecture. Sometimes I had my vote on it (I didn’t know about any other architecture), sometimes it was already decided for me by a software architect. But I never stopped to wonder why use 3-layered for this specific case? is there a better architecture for this problem? how did the architect decide to use 3-layered architecture specifically?
We can now take a closer look at the layered architecture and answer those questions for ourselves.
What exactly are layers?
Layers in a Layered architecture are a collection of modules (classes in Java world, if you will) with common functionality.
In a layered architecture, layers are stacked on top of one of another:
Componentes from one layer are only allowed to communicate with the components from the layer one level below:
The most common type of Layered Architecture is a 3-Layered Architecture.
3-Layered Architecture consists of:
- Presentation layer
- Application layer
- Data layer
Presentation Layer
Presentation Layer is our connection to the outside world. This is where we handle all the incoming requests to our application and return a response.
This layer is also the first line of defense in our application because this is where we do authorization checks.
One layer below Presentation Layer is Application Layer.
Presentation Layer relies upon Application Layer to do all the functions the system should provide. Thus Presentation Layer has dependency only on the Application Layer.
Application Layer
Application Layer is where we develop all the functions our application should provide. So in terms of a Web Shop, this is where we implement functions for addArticleToBasket, proceedToCheckout, cancelOrder ...
This is also where we do all our validations. For example, before adding an article to the customer's basket we can check that the customer has enough money to pay for the article.
Application Layer relies upon Data Layer to save all the data for later use or fetch some previously-saved data. Thus Application Layer has dependency only on Data Layer.
Application Layer returns the result of its calculations back to the Presentation Layer.
Data Layer
Data Layer handles the persisting of our data. It communicates with the Database and has no further dependencies.
Data Layer returns its data back to the Application Layer.
Java Spring Example of 3-Layered Architecture
If you are familiar with Spring Framework, chances are, you’ve used 3-Layered architecture.
In Spring applications our Controller classes are in a Presentation Layer. Our Service classes are in an Application Layer. Our Repository classes are in a Data Layer.
And between those layers, we have various objects used for communication:
- Data Transfer Object (DTO) — is sent by a client from outside of our application. DTO is received in the Presentation Layer (Spring Controller class). Presentation Layer sends DTO objects to the Application Layer (Spring Service class). Application Layer returns DTO objects as a result back to Presentation Layer
- Domain Object — the object that the Application Layer works with. It can be created somehow out of DTO or Entity Object, or both, there are actually no rules here
- Entity Object — the object that Presentation Layer works with. Application Layer sends Entity Objects to Data Layer and also Data Layer sends Entity Objects to the Application Layer. Data fetched from the database will be mapped to an Entity Object. The object we want to persist in the database has to be mapped to an Entity Object first.
Here, in the diagram, we can see how the Layers communicate using DTO, Domain and Entity objects:
We can see that in 3-Layered Architecture, the database is the most important component. All other components depend on the database directly or indirectly.
This is in strong contrast with Domain-Centric Design which I will cover later in another blog post.
Now we can write up a code example to demonstrate all the things we covered so far.
Code Example
First, let's start with our POJOs: Data Transfer Objects, Domain Objects, Entity Objects.
Data Layer
Next, we can add our Data Layer that will be our connection to the database. I will use JPARepository from the Spring Data :
Application Layer
In the Application Layer, I created a simple mapper class. I use the mapper class to transform Entity model to DTO. It's a good practice to never return Entity objects to the Presentation Layer, and especially not to the client.
In the Application Layer I also created CustomerService class. This is where we add all our functionalities concerning the Customers of our application.
Presentation Layer
In the Presentation Layer we got our Controller classes. This is where we define our REST routes.
Pros and cons
What are the pros and cons of this type of architecture. Why did it become so popular and so widely used?
Pros:
- Layers are isolated — changes to one layer don’t affect the other layers
- Separation of concerns — each layer handles one aspect of our application and that makes our code more manageable
- Layers can be independently tested
- Defacto standard — it's well known by developers so everybody can easily find its way through the codebase
- A quick way to get the application running without much complexity
Cons:
- might be too much for simple CRUD — going through 3 layers only to create one database record
- Layers all make a single application. Changes to one layer require redeployment of the whole app
- Every Layer has a direct dependency on a layer below. This makes a tight coupling. It is not easy to swap out a layer with another one.
Another con I notice while working with a layered architecture: I would like to have code reuse within the same layer. But it's not allowed for a component to call other components in the same layer. So how do we handle a situation like this? I personally allow a component to call other components from the same layer, but this could lead to dependency hell.
This sums up my tutorial about the Layered Software Architecture. Please feel free to share your thoughts in the comment section. Until next time … 🍻
