With separation of data, processing bundling and dependency management in mind the Reflex platform was designed to consist of clearly distinguished components.
Models are a first class principle in the Reflex platform to support domain specific and generic coding. While models are meant to be used in any domain there are typical use cases in Reflex like:
Read more about modeling.
Modules are the components that contain processing code and are automatically detected and loaded by a Reflex application. The processing code of modules is typically concerned with:
In the case that modules have a general purpose for other modules they may support modules APIs for inter-module communication (e.g for dependency injection).
Modules communicate with the Reflex platform and with other modules through IOC contracts and spaces which are mediated by the wire framework.
Read more about modules.
Module APIs declare contract interfaces for the wire IOC framework to support inter-module communication.
On one side the contract interfaces are bound to implementing spaces by supplying modules. An example could be an expert registry.
On the other side the contract interfaces are imported by consuming modules. An example could be an expert registration.
Read more about module APIs.
A Reflex application is a zipped bundle containing libraries, configurations and launch shell scripts. The libraries include modules and models, with all their dependencies.
The application can be directly started with the launch scripts (assuming Java Runtime Environment is present).
When an application starts it automatically detects and loads all its modules.
Read more about applications.