Module

Modules are logical compartments to assist developers in creating and maintaining well modularized code. A Module only belongs to a single Layer, but many Modules can exist in the same Layer. Composite access is limited to;

Composites within the same Module, with Visibility set to Visibility.module (default).
Composites from Modules in the same Layer, with Visibility set to Visibility.layer
Composites from Modules in Layers below, with Visibility set to Visibility.application

Modules contains a lot of the Qi4j infrastructure, which are the enforcers of these wise modularization principles.

Modules are a concept implemented with a chained set up artifacts;

ModuleModel - What makes up the Module, i.e. the code itself.
ModuleResolution - Where the Module sits in the Structure.
ModuleBinding - How the Module is wiring its Composites to other Modules.

Standard domain-oriented application seldom (almost never) need to deal with these artifacts. Instead, the Composites of the domain will reside in Modules, and the runtime will ensure that the visibility rules are followed, according to the assembly declarations performed at start-up.

It is not possible to modify the Modules, their resolution nor binding in any way after the application starts. This might be changed in the future, to allow upgrading of Modules, adding new Modules as plug-ins on the fly, and similar dynamic features.

public class MySubSystemMixin
implements MySubSystem
{
@Structure ModuleBinding module;

    private void validateLayer()
    {
        ModuleResolution resolution = module.getModuleResolution();
        LayerModel layer = resolution.getLayerModel();
        if( ! layer.getName().toLowerCase().contains( "domain" ) )
        {
            String mess =
                "MySubSystem must be in a Layer with \"domain\" in the name."
            throw new InvalidLayerException( mess );
        }
    }
}

Accessing the ModuleBinding, ModuleResolution and ModuleModel is not meant for normal applications. Tools that visualize the application structure or validates project rules are typical candidates needing this information.

For even more intricate tooling and highly specialized subsystems, there are additional ModuleInstance and ModuleContext available as well. It is beyond this scope to discuss their use.

Qi4j and the Qi4j logo are trademarks of Richard Öberg, Niclas Hedhman and the members of the Qi4j Core Team. See Qi4j licensing for more information.