Today many of Java developers work on Spring Web Application Framework. Today we’ll discuss most the problematic part of a Spring web application. There are a lot of functionality comes with Spring Framework and that is the main reason to choose this framework. Developers who are using Spring Framework in their applications are good to talk about the benefits of dependency injection.

Unfortunately, they are not good enough to take advantage of their advantages such as:

• Single responsible theory
• Separation of concerns 

If we look at a spring operated web application, the hurdle is that the application is implemented using these common and uniformly incorrect design principles:

1. The domain model objects are used only to store the data of the application.
2. The business logic lies in the service layer which manages the data of the domain objects.
3. The service layer has one service class per each entity of the application.

Q. Its common design principles and use from a long time, Then how it can be wrong?

A. For the answer to this question, you need little bit patience to read this article and at last, you’ll have your answer. So let’s find out.

See More:

Cannot determine embedded database driver class for database type NONE – Spring Boot Problem
When I was beginner in Spring boot and most of...

Spring Web Application Defenders

Senior developer and architects follow above design principles from long-time with these old fashion way and that is the main reason “Why Spring web application looks like a demon for a beginner”.

[tmh_article_ads]

But the Spring Defenders who work for long-time with hard-working are very good to defend their opinions. One of their favorite arguments is that our application follows the separation of concerns principle because it has been divided into several layers and each layer has specific responsibilities.

Q. What is the Separation of concerns principle?

According to Wikipedia, The separation of concerns principle is defined as follows: Separation of concerns (Soc) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.

A typical Spring web application has the three layers:

• The web/controller layer which is responsible for processing user’s input and returning the correct response back to the user. The web layer communicates only with the service layer.
• The service layer which acts as a transaction boundary. It is also responsible for authorization and contains the business logic of our application. The service layer manages the domain model objects and communicates with other services and the repository layer.
• The repository/data access layer which is responsible for communicating with the user data storage.

Yeah, they have correct point that Spring Web application use SoC principle but it follows in some level, the reality is that the application has an inflexible service layer which has too many responsibilities.

Let’s discuss the two major problems in the Service layer:

• Our business logic can be found from the service layer

This is a problem because the business logic is scattered around the service layer. If we need to check how a certain business rule is implemented, we have to find it first. This might not be easy.

See More:

Spring Boot + Kotlin + AngularJS + WebJar CRUD Example Part 1
Today we’re going to learn CRUD example using Spring boot,...

Also, if the same business rule is needed in multiple service classes, the odds are that the rule is simply copied from one service to another. This leads to a maintenance nightmare.

• The service layer has one service class per each domain model class.

This problem violates the single responsibility principle.

Q. What is the Single responsibility principle?

According to Wikipedia, The single responsibility principle is defined as follows:
The single responsibility principle states that every class should have a single responsibility and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

The service classes have a lot of dependencies and a lot of circular dependencies. The service layer of a typical Spring web application does not consist of loosely coupled services which have only one responsibility. It is a more like a set of tightly coupled and monolithic services.

This makes is it hard to understand, maintain and reuse.

This might sound a bit harsh but the service layer is often the most problematic part of a Spring web application.

Good for Spring Developers

I know that the current situation is bad according to the above statement but it’s not totally bad for you.

See More:

What is Spring Framework, why should we go for it?
Spring is a framework, which provides a bunch of classes,...

Let’s find out how we can change and resolved above-mentioned problems by performing two steps.

First of all, we have to move the business logic of our application from the service layer to the domain model classes.

The reason why this makes sense should be clear to us if we think of the following example:

Let’s assume that China is a Service class and Pakistan is a domain model object. If China tells Pakistan to start the war against America, obviously Pakistan want a veto right to China decision. Maybe Pakistan can’t go against China. But logically they don’t want to start a war against America.

Sorry no, offend for any country. So let’s move on to our main topic.

[tmh_article_ads]

Moving the business logic from the service layer to the domain model classes gives us three advantages:

1. The responsibilities of our code are divided in a logical way. The service layer takes care of the application logic and our domain model classes take care of the business logic.
2. The business logic of our application is found in a single place. If we need to verify how a specific business rule is implemented, we always know where to look for.
3. The source code of the service layer is cleaner and does not contain any copy paste code.

Secondly, we have to divide the entity-specific services into smaller services which serve only a single purpose.

For example, if our application has a single service class which provides CRUD operations for persons and operations related to user accounts, we should divide it into two separate service classes:

• The first service provides CRUD operations for persons.
• The second service provides operations related to user accounts.

This gives us three big advantages:

1. Each service class has a logical set of responsibilities.
2. Each service class has fewer dependencies which means that they are no longer tightly coupled giants. They are smaller and loosely coupled components.
3. The service classes are easier to understand, maintain and reuse.

These two simple steps will help us to clean up the architecture of our application, and increase the productivity and happiness of our fellow developers.

Hope this article gives you answer of all you arise questions and meanwhile if you’ve any other question then comment us below.