Right, the ModuleDefinition (or preferably some new name so we don't have definition.getDefinition() anymore) should be reserved for the static parts: name, type, and the config itself - whereas ModuleOptionsMetadata will likely become more generalized (perhaps just ModuleMetadata) as it evolves to support not only the metadata about the --options but also the profiles to activate and classpath urls to be added. A Module instance would require the static part as well as the "metadata" that could change (i.e. there is a 1:N relationship between the ModuleDefinition and the instances of a runtime module based on that definition but each able to use different --options values).