I have seen a project which uses Maven submodules. The project itself is a spring boot application that exposes Restful API endpoints for a microservice ex: Customer Service (getCustomers, createCustomers etc); consisting of standard model classes, repository, service interface&implementations, controllers etc.
Is there a good reason why we want to make model classes, repository, service interface&implementations, controllers, submodules ?
To be clear, i'm comparing these 2:
1) Normal case:
Project src main java dao model service controller resources test ... pom.xml
2) Submodules case:
Project dao src main java dao resources test ... pom.xml service src main java service resources test ... pom.xml
Why go for no 2?
To me this structure looks really complex with each pom.xml in each submodule folder..
I have worked with varying project structures like
There are pros and cons of each.
For 1st Approach
Everything is in single project and everything is accessible from everywhere.
Eg. Controllers can see and use directly the persistence entities. There is no elegant and obvious way to impose the layering.
Even if you put interfaces and implementation in separate packages, it becomes difficult to achieve Dependency Inversion like when you want controllers to depend only on API and not Implementations.
For 2nd Approach
Here we have different source code repos for each layer. This kind of structure enables layering very well as we can manage dependencies between layers through maven. Enables us to achieve dependency inversion with clean dependencies between layers.
But this approach soon causes explosion of maven projects and their CI/CD builds. This also forces users to push code in specific order only.
For 3rd Approach
This is like a sweet spot between above 2 approaches.
Here we have single code repository, preventing multiple repos and builds. With submodule maven dependencies, we can achieve clean layering with dependency inversion.