Return to Answer

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 services implement the hexagonal (micro) architecture, one more advantage is in the "adapters". These can be implemented later and replaced without changing the core of the application, or the logic of the module we are working on. It means that we can move the implementation details to a specific module (say *infrastructure") and let its implementation for later or code it in parallel with the business logic.

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.

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 modules separatelly, providing them with different SDLC.
• Versioning concrete pieces of code or logic
• Code reuse (as shared libs)
• Archetyping (look for maven archetypes for more information)

If the application implements a hexagonal (micro) architecture, one more advantage could be on the "adapters". These can be implemented later and replaced without changing the core of the application, or the logic of the module we are working on.

Nevertheless, whether these things are advantages or not depends on the context. You have to decide if they are relevant or not.

Worth nothing to say, sometimes developers use these and other resources just because they can or because they became their golden hammer, regardless of its suitability.

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 services implement the hexagonal (micro) architecture, one more advantage is in the "adapters". These can be implemented later and replaced without changing the core of the application, or the logic of the module we are working on. It means that we can move the implementation details to a specific module (say *infrastructure") and let its implementation for later or code it in parallel with the business logic.

To my experience, for small apps or for very small services you are right; maven modules introduces unnecessary complexity. Both technical and cognitive (they are a bit "harder" to reason about for juniors or developers without the proper background)

However, modules might help you to "visualize" in a easy way the boundaries within your application, what makes easier to make decisions when it comes to place components in one or another scope / boundary.

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

Other advantages of implementing modules could be:

• different SDLC for each module.
• versioning
• modules evolving at different speed and time. You know, changing for different reasons
• code reuse (as shared libs)
• archetyping (look for maven archetypes for more information)

If your application follows an hexagonal (micro) architecture, one more advantage is that the "adapters" can be implemented later and replaced anytime without having to change the core of the application, allowing you to abstract yourself from some implementation details and focus on the business of the module you are working on.

Whether these are advantages or not depends on the context. Basically, you have to decide if they are relevant or not.

Sometimes, engineers and architects just use modules because -they can- or because it became their -golden hamer-. Regardless its suitability.

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 modules separatelly, providing them with different SDLC.
• Versioning concrete pieces of code or logic
• Code reuse (as shared libs)
• Archetyping (look for maven archetypes for more information)

If the application implements a hexagonal (micro) architecture, one more advantage could be on the "adapters". These can be implemented later and replaced without changing the core of the application, or the logic of the module we are working on.

Nevertheless, whether these things are advantages or not depends on the context. You have to decide if they are relevant or not.

Worth nothing to say, sometimes developers use these and other resources just because they can or because they became their golden hammer, regardless of its suitability.