Why Modular?

Building a modular system can shorten development times, improve code management, prolong system life span, and provide a more efficient deployment of different packaging matching a different set of users’ requirements.

Types of modularity

Compile Time Modularity

In compile-time modularity, the developer is required to declare which modules an application will use. When the required modules change or when a module is updated, the whole system must be re-built. Most developers think of compile-time modularity when modularity comes to mind.

Run-time modularity

On the other hand, a run time modular system can dynamically be deployed by simply including different modules in the deployment or adding new modules to an already running system. 

Run-time modularity is based on plugins or Micro-services.

The Benefits of Run Time Modular System based on plugins

• Services, Domain Model definitions, and APIs are defined inside a set of physically isolated executables (jars when Spring is used.).
• Different development teams are responsible for different plugin-sets with zero or close to zero communication among teams. 
• A new version of a plugin-set doesn’t require tests outside of it.
• The same system can be deployed in endless combinations of features meeting a fine granularity of customer needs without compiling dozens of combinations while maintaining multiple branches one would be required without a good plugin technology.
• Extensibility takes a completely new level where changes and new versions of an extended plugin can be automatically used by extending plugins even without recompilation.
• Unlike the Micro-services pattern, maintaining the dependencies uni-directional is easy, the never fully solved issue of database splitting in Microservices is not present as well as performance hits serialization, deserialization and communications may hit a micros-services based system.

Current modularity patterns.

Most modular systems including Spring’s own multi-modules one are of a compile-time type. That is, dependencies must be declared before a system is compiled, and a new combination of services requires a new build process preceded by dependencies declarations. This is normally followed by a full set of testing cycles for all of the system components.

A Maven-based project also uses the compile-time paradigm where all dependencies must be known before compilation.

Micro-Services are clearly of the run-time type, however, topology decisions on Micro-Service are tough, read https://dzone.com/articles/7-things-to-consider-while-moving-to-a-microservic

When using an in-process plugins system, de-coupling takes a different level even when using the same database. A service provider (in a plugin) can be extended and changed without the intervention of the development team responsible for that service and without affecting other services dependent on it.

Run Time Modularity via In-process plugins.

A run-time plugins system should support in its plugins system:

• Dependency injection among plugins, to any depth. That is, plugins must be injectable into other plugins while the injected plugins can have other plugins injected into them. Injected plugins should have no knowledge of the plugins they are injected into.
• The container, that is, the Spring Boot application doesn’t have to know anything about plugins extending and servicing it.
• There should be no limitation to what a plugin/module can do in the context of Spring development, this should include REST API definitions, business services, new JPA entities, event bus support, etc.
• In the spirit of re-use, existing plugins should be injectable into new plugins capable of extending them, this should be possible with REST services, business services, and the JPA entities model.
• When supporting a Software As A Service (SaaS)  cloud-based system, support for multiple versions of the same plugin/module may be required.