Add detailed comparison with alternatives like Gradle and Maven multi-module projects to make reasons for adopting Spring Modulith more convincing

[cassis163]

Something that I'm kind of missing in the documentation is a detailed comparison of Spring Modulith with multi-module projects powered by build tools like Gradle and Maven. For AFAIK, if any team wants to seriously consider building a modulith, they would have to research all the different ways of doing so. And it is actually not that simple as there is something to be said for all techniques.

For example, Spring Modulith is slow. And I deeply care about performance. Anyway, a Gradle multi-module builds caches for every module, making build times faster. Additionally, it is possible to run tests for separate modules. Maybe the last argument is not too convincing as I heard some rumours that Spring Modulith is doing something about that.

Just for the sake of clarity, you can decouple build times in a multi-module project in Gradle by dividing a project into implementation and API modules like so. The APIs only contain discrete code like interfaces and DTOs.

Notice how:

1. There are no circular dependencies
2. The API modules do not depend on any other modules (allowing creation of different caches)

How can an implementation module depend on an API module that only contains interfaces and still access concrete functionality you ask? Well, that is done by using dependency inversion. Lets say stock-impl wants to use the product-impl to retrieve products from a database. It would have to depend on the product-api module and inject an interface bean. Lets call that interface IProductApi. product-impl has a concrete implementation for this interface, which means that if IProductApi is injected in stock-impl, Spring will automatically resolve that interface to the one specified in product-impl. So even by decoupling build times for stock and product, it is still possible to make them work together.

For more information about this performance argument, I would highly recommend this article by Chris Richardson.

The arguments for performance gains with different technologies are just examples and not sole reasons to adopt one solution over another. My intention is to demonstrate that choosing the right tools for the job is often not that simple. Spring Modulith could help engineers along by providing more information on the subject while making a more compelling argument for the framework itself.

[odrotbohm]

I think you're running into a couple of misconceptions here. Let me try to approach them one by one:

Something that I'm kind of missing in the documentation is a detailed comparison of Spring Modulith with multi-module projects powered by build tools like Gradle and Maven.

It's not missing. The reference documentation does not touch on that topic because it's reference documentation, it's not a general purpose guide to how to set up projects. Just as the Spring Cloud reference documentation solely describes SC features, and does not give advice on fundamental architecture and design of microservices.

For AFAIK, if any team wants to seriously consider building a modulith, they would have to research all the different ways of doing so.

Welcome to the world of decision-making. And software engineering in particular. :)

For example, Spring Modulith is slow.

That's a non-statement because you don't explain what you mean by that. Judging from the following paragraph, I think what you mean by that is the following: one can get fundamental dependency and visibility governance by using build system modules, coming with the advantage that they can be built individually and the build systems applying different levels of smartness to achieve that and thus build a system faster.

That's correct. It just doesn't have anything to do with Spring Modulith. The reason we show single-build-module examples primarily is that examples need to be concise and usually focus on a particular feature of Spring Modulith. Overloading those with separate build modules would add nothing but noise. Spring Modulith's application module model is based on the classpath arrangement. It fundamentally is not concerned with the build module structure. Thus, if you decide you'd rather use that to govern dependencies, all good. It just needs to be remarked that…

• On the downside, you have to deal with more individual projects, more build metadata, and you expose the internal structure of your application in the form of the artifacts produced. This means that users or your team have to assemble the individual elements into a running application again, typically by an additional build module.
• On the upside, the build-module-based approach allows scoping third-party dependencies to individual modules.
• A build module-based approach still leaves the following topics from being solved: running integration tests for individual modules, support for event-based module interaction, documentation generation for the module arrangement, support for exposing architectural information at runtime and observing module interactions.

For more information about this performance argument, I would highly recommend this article by Chris Richardson.

With Chris being a former colleague and fellow proponent of balanced software architecture, rest assured I am familiar with his work. 😉

Regarding build performance, I would highly recommend the release announcement of Spring Modulith 1.3. We describe a new test optimization feature that skips integration tests that are not affected by changes made to the repository, potentially further optimizing on build performance by piggybacking on whatever smarts the build system of your choice applies.

[cassis163]

Thanks for your reply. I just want to point out that I oversimplified some statements to make them less vague (which did not work). In fact, we have since adopted Spring Modulith. In our case, we had a microservices architecture with a small team. There was a mismatch between our department structure and our software architecture. So we decided that we wanted to maintain our app's structure, but ultimately simplify our codebase and make it work for us and not the other way around.

Caching test results is great. I think that I was unaware its introduction in version 1.3 at the time I initially wrote this post.

This is off-topic, but maybe I can ask this here. Is there a way to deal with database-per-module pattern in terms of performance? At the moment, we have a number of datasource beans that load in series. This delays the startup time significantly. From my point of view, it can be resolved by:

• Using schema-per-module instead so that only one datasource bean is required (unless you want private schema-per-module as that would require multiple users in one database, which in effect requires multiple datasource beans).
• Parallelising the startup of datasource beans as much as possible.

There is a definitely a chance that I missed something and that there is a way to sort of parallelise module-specific bean startup.

Thats it, for the most part I'm quite content with Spring Modulith and the modular monolith concept in general!