Last updated: 2025-05-29
Modules tab - backgrounds
After the multi-module setup option has been activated for a project, the Modules tab is available. A multi-module project can be used to divide a monolith into several, logically linked modules to improve the maintainability of the code and collaboration among developers. Here is a useful article on best practices for multi-module projects.
In a multi-module project the build file is extended (Gradle) or divided (Maven). Each project initially has the modules base
and web
. In base
, basic functionalities are provided that all other modules can use - for example, the configuration of Liquibase or the provision of a MailService
. All artifacts for a possible frontend are contained in web
(.js
, .css
, etc.). In addition, all modules of the application are combined here so that the final, executable .jar
is generated.

Your custom modules and their assigned entities
Your custom modules created in the Modules tab are always integrated between web
and base
. When custom modules reference each other, the module structure is automatically adapted so that only required and valid references remain - indirect dependencies are automatically available through Gradle/Maven anyway.
Module assignments
All entities, data objects, enums, custom controllers and security configs can be assigned to a module so that the generated code is contained in the respective module. As soon as custom modules have been created, the corresponding dropdown is visible in the form. Entities can also be selected when creating or editing modules, so that multiple entities can be reassigned at once.
As the module structure creates real dependencies, the artifacts are only available according to this structure. Therefore, an invalid selection in the Bootify Builder is either not available or blocked with a validation error. Relations between entities in different modules can only be unidirectional. The "reference check" for the CRUD functionality cannot be generated in this case as well.
Generally it is recommended to proceed in the following order:
- Creation of your custom modules and their dependencies
- Assignment of the security configs
- Assignment of entities from top (
web
) to bottom (base
) - Assignment of the remaining objects
For easier usability there are some fallbacks in the Bootify Builder when changing modules: if referenced types on fields or controllers are no longer accessible, they are reset to String
. A relation is automatically switched to unidirectional if the linked entities are in different modules. This can be avoided by assigning several entities at once in the Modules tab. After completing the assignments, the final setup should be reviewed.
An enum used in a security config must always be in the base
module, as the protected paths can be selected from all modules (higher or lower relative to the security config's module).
Integration tests
If the integration tests for the project are enabled, the test
part of base
contains in particular the abstract class BaseIT
. All integration tests of the application extend this class so that the common context (including any Testcontainers) can be reused. All other modules reference the test-jar
of base
for this purpose. Any test data is provided by the respective module so that further test dependencies are integrated if required. Transitive dependencies are not possible for test-jar
.
Integration tests also execute the clear scripts after all tests have been completed (executionPhase = Sql.ExecutionPhase.AFTER_TEST_CLASS
) to avoid blocking the tests during development. In some modules integration tests are executed with the "nosecurity"
profile. This deactivates the autoconfiguration, as Spring Security already exists as a dependency, but is not yet configured in the respective module.
The Bootify Builder is a powerful tool for configuring complex Spring Boot applications with multi-module setup and Spring Security. Depending on the use case, further aspects can be optimized, but the generated code provides an excellent basis with numerous best practices.
See Pricing
or read quickstart