Understanding Code Structure for Spring Boot
Overview
The application's maintainability can be easily judged by how the code is structured. Code in which classes are scattered without restriction leads to a complex and tangled structure and directly affects the manageability and releases.
Such a codebase is called "spaghetti code".
Therefore it's essential to structure code well from the beginning.
Introduction
Though spring boot does not advocate any specific structure, some best practices help the developer to create manageable code.
Best Practices for Structuring Code
About Typical Layout
A typical layout for maven projects contains different directories, each for specific types of files to be placed.
-
src/main/java:
Package should contain source java classes. We should not create classes directly in this folder; rather, we should have our package. For example, we have the com.scaler.ems package under this folder. Typically package name is the same as that of the group id.
-
src/main/resources:
This folder should contain configuration files, properties files, yml files, and other such configurations. -
src/test/java:
This folder should contain unit test classes. -
src/test/resources:
This folder should contain configuration files used in tests. -
target:
This folder contains compiled classes and generated project artifacts.
Using the “default” Package
A class not part of any package is in a default package. For example, any class in src/main/java will go into the default package.
Use of default package is discouraged and should be avoided as it may cause issues in automatic bean scan.
Locating the Main Application Class
Spring recommends keeping the runner class in the root package, and actual business logic classes should be kept in sub-packages. There are a couple of advantages to it.
- It can automatically identify and scan @Entity classes for a JPA project.
- All the beans in the sub-package will be automatically discovered without any additional @ComponentScan.
Approaches in Layout Structure
We can structure your code in two ways:
- Structure by layer
- Structure by feature.
It affects the application's cohesion and coupling factors.
A good structure has low coupling and high cohesion.
Let's understand each of them.
Structure by Layer
In this structure, classes are placed in the package based on the layer it belongs to. This method causes low cohesion within packages because packages contain classes that are not closely related. Below is an example of packaging by layers:
The typical structure looks like the one below.
On observing this structure, we see that there are:
- High coupling:
Because classes tend to change in all the packages to implement the functionality. - Low cohesion:
Because each package contains unrelated code.
This structure loses coupling and cohesion.
Structure by Feature
In this structure, packages contain all classes required for a feature. The feature-based packing ensures that closely related classes are kept together. An example of this structure is given below:
On observing this structure, we see that there are:
- Low coupling:
Only classes within the package is touched to implement the functionality. - High cohesion:
Set of related classes is kept together as they usually get changes.
Further, this structure aligns well with the microservices principle.
Conclusion
In this article, we have covered.
- Good practice for structuring the code
- Advantages and disadvantages of different structuring styles.
- Spring boot recommended code and package structure.