Maven Dependency Scope Applied

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. This specific architecture has been intentionally chosen, assuming that it is familiar to everyone. What should let us focus on Maven dependency management by resolving these issues?

Three-Layer App Sample

The source code for this can be found at the following link.

In line with the three-layer architecture, the goal is to have layers that remain isolated from each other, with interactions occurring only through the APIs of nearby layers (modules). 

The typical Maven module configuration for this kind of structure would look something like this.

<!--web module pom.xml -->
<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>service</artifactId>
    <version>1.0.0</version>
  </dependency>  
</dependencies>

<!--service module pom.xml -->
<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>dao</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

Our main concern here is that this setup needs to provide the level of encapsulation we desire for our modules. For instance, 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.xml files.

Improved Three-Layer App Sample

The source code for this can be found at the following link.

<!--web module pom.xml -->
<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>service-api</artifactId>
    <version>1.0.0</version>
  </dependency>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>service</artifactId>
    <version>1.0.0</version>
    <scope>runtime</scope>
  </dependency> 
</dependencies>

<!--service module pom.xml -->
<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>dao-api</artifactId>
    <version>1.0.0</version>
  </dependency>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>dao</artifactId>
    <version>1.0.0</version>
    <scope>runtime</scope>
  </dependency>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>service-api</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

<!--dao module pom.xml -->
<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>dao-api</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

Two new modules have been added in this improved version: the dao-api and the service-api. Moreover, apart from the default compile scope, some dependencies now have the runtime scope. According to Maven's Dependency Scope documentation:

• Compile: This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, 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.

Conclusion

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.