To get started, we are going to take an example of a typical three-layer app to analyze the module boundaries and the challenges faced in managing them.
The typical Maven module configuration for this kind of structure would look something like this.
Our main concern here is that this setup needs to provide the level of encapsulation we desire for our modules.
It would still be possible to use any public classes declared in the dao module within both the service and the web modules.
This could break down the initial design and result in a tightly-coupled application as it grows and evolves.
Given the above, let's have a look at how we can improve this solution to gain better control over module boundaries by restructuring our initial app sample a bit and updating its pom.
Two new modules have been added in this improved version: the dao-api and the service-api.
Apart from the default compile scope, some dependencies now have the runtime scope.
Compile: This is the default scope, used if none is specified.
Compile dependencies are available in all classpaths of a project.
Those dependencies are propagated to dependent projects.
Runtime: This scope indicates that the dependency is not required for compilation, but is for execution.
Maven includes a dependency with this scope in the runtime and test classpaths but not the compile classpath.
The result of this configuration is that only the DAO interfaces from the dao-api are available in the service module, ensuring that there's no exposure of the dao internals.
The same applies to the web module regarding the service.
While adding new modules might require more effort and might be considered as an extra complexity, it is a reasonable trade-off for improved encapsulation, which is essential to adhere to the chosen design.
Through this article, we have shed light on a simple yet frequently overlooked approach to managing dependencies in the multi-module project with Maven.
While it may require a fair amount of effort, its application can result in a significant improvement in the control of module boundaries.
This is particularly true when possible alternatives like the Java Platform Module System or ArchUnit are not viable for some reason.
Opinions expressed by DZone contributors are their own.
This Cyber News was published on feeds.dzone.com. Publication date: Mon, 22 Jan 2024 17:43:03 +0000