Spring Boot REST Java Microservice: Why Use Maven Submodules?

Question

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..

Answer 1

To my experience, for small apps or very small services you are right, maven modules make thing unnecessary complex in two ways: technical and cognitive.

However, modules can be of much help when:

• Services are complex and we need a way to visualize their most relevant boundaries so that developers can find or add features in the right place quickly.

• Decomposing services. Even microservices can be composed of several but smaller services. Using maven modules can provide us with valuable feedback about the interaction of the components and the best way to decouple them. Or a reason to leave where they are. Moving code to a standalone process will be easier this way.

A well-modular application can enforce a healthy separation of concerns too and reduce the coupling between elements of the application.

Modules can be the tactical answer to a strategic question or need too. For example:

• We need/want to develop, evolve and maintain features or capabilities separately. In other words, providing them with different development life cycles.
• Versioning of code or logic
• Code reuse (as shared libs, aka microkernels)
• Services' archetyping (look for maven archetypes for more information)

If the service implements a Hexagonal architecture, another advantage is in the "adapters". These can be moved to a different module, constraining any possible coupling between abstractions and implementation details. At the same time, the new module can be implemented in parallel. While one member of the team is focused on the business, others focus on the adapters.

Testing also matters. It's not the same testing a small module (in terms of time and complexity) than testing a whole service which usually involves many more "moving-things" to take into account.

Answer 2

I have worked with varying project structures like

1. Everything is in same maven project, single module, different packages.
2. Every layer even api and implementation in different maven projects, and repos.
3. Single maven project but submodules for different layers.

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.