As said before, we can organize the application's source code in Java packages and project modules, respectively. Project modules group related functionality together into separately buildable sub-projects. They are usually specified by the build systems.

At first, the motivations behind splitting up project modules are quite understandable. Grouping Java code and packages into related modules creates a clearer view for the developers, enables a better structure, and increases cohesion.

Another reason for multi-modules is build time performance. The more complex our software project becomes the longer it will take to compile and package it into artifacts. Developers mostly touch few locations in the projects at a time. Therefore, the idea is to not always rebuild the whole project, but only the modules necessary in order to apply the desired changes. This is an advertised advantage of the Gradle build system, to save time by rebuilding only what has changed.

Another argument for this practice is the possibility of reusing certain sub-modules in several projects. By building sub-projects into self-sufficient artifacts we could possibly take and include a sub-artifact in another software project. For example, a common practice is to design a model module that contains the entities of the business domain, usually as standalone plain old Java objects (POJOs). This model would be packaged to a JAR file and reused as a dependency in other enterprise projects.

There are, however, some drawbacks, or rather, illusions to this practice.