Modularity and Extension
In this section, you will learn how to create modular and extendable systems with Jmix.
Splitting a complex system into a set of components makes it more manageable and allows for reusing functionality. For example, if you build, say, the User Management as a separate component, you can delegate its implementation and maintenance to a separate team, as well as to use it in multiple applications created in your organization, because most probably they have the same requirements in this area.
Another feature that improves productivity is the ability to create new components on the basis of existing ones, by modifying and extending their functionality. If you take the example with the User Management component, you can imagine that you need to add a field to the User entity in a particular application that uses the component. So the component is extendable if you can add such a detail right in your application without the need to build a separate version of the whole User Management component.
Subsystems, Add-ons and Modules
The word "component" is so overloaded with meanings that in the context of Jmix modularity we will use a more specific term - subsystem. A subsystem is a separate component of a Jmix application providing some functionality. There are two categories of subsystems:
-
Core subsystems provide system-level functionality and are included in most projects.
-
Add-ons are optional subsystems that can be included in the project on demand. The public add-ons are available at Jmix marketplace. You can also create custom add-ons and use them within your organization.
Below is a possible structure of an application that uses the core subsystems, the public Reports add-on and a custom User Management add-on:
We will use the term module in the same meaning as in the IDE. A module is a collection of source code files and build settings that is built and packaged into a single JAR file.
A Jmix subsystem consists of one or multiple functional modules, each accompanied by a Spring Boot starter module.
A subsystem can depend on other subsystems. For example, a User Management subsystem would probably depend on Data Access and UI subsystems, which in turn depend on the Core subsystem.
Technically, dependencies between subsystems are expressed by dependencies between their functional modules. See more details in the Creating Add-ons section.
Extendable Applications
Functionality of add-ons (actually, of any subsystem including core) can be extended and modified by the application or by another add-on. The Extending Functionality section describes what can be extended and how to do it.
The obvious consequence is that you can customize some functionality provided by add-ons used in your application and better adapt them to your needs.
Another possibility is creating applications that can be customized for a particular industry or customer without modification of the original product. In order to achieve this, you need to put the main application functionality into an add-on, and use the application module just as a thin runner.
Below is a structure of an extendable application:
To create a customized version of the application, you need to replace only the runner module with another module that contains customizations:
The customized application project contains only extension functionality, the Application add-on is used as a dependency and is not modified.
