Module Pattern

Module Pattern

Design patterns are a well-established concept for the design of classes and their relationships in object oriented programming. Build tools like Maven can encourage us to think of similar patterns for modules or libraries. In Maven, every module or library (a project in Maven terms) is described by a project model (pom file). Modules which share similar pom files can be the building blocks of pattern of modules.

Below are a number of ideas of different types of modules, which could constitute module patterns (these are no patterns as yet, although some patterns emerge naturally from these types)

Architecture Based

TypeDescription
Interface-ModuleContains only interface definitions. They can only depend on other Interface-Modules.
Plain-ModuleModule does not depend on any other modules.
Proxy-ModuleModule works as a facade to the functionality of other modules. But modules does not add much additional functionality.
Application-ModuleModule, which uses other modules and adds its own functionality.
Included-ModuleModule, which must be executed inside another module.
XPlain-ModulePlain modules, which only depends on Interface modules.
Module-Execution-EnvironmentThis is not really a module but the framework, which provides the execution environment for the modules
Module-LauncherThis is a application, which decides on, which modules are to be started and provides an interface to the surrounding execution environment. E.g. event such as drag and drop of files on the application icon.

Functionality Based

TypeDescription
UtilityA module which provides simple but many functions, which are used by many other modules.
ExtensionA module, which provides additional functionality for the application but must not be there. Can be grouped with other extension modules. It can be specified whether another module needs 0..n, 1..1, or 1..n of these group to operate.
Third-PartyA module which contains code or reference to libraries from third parties. It is not assumed that there will be very little changes to this third party code in order to assure upgradability.
PlaygroundModules which are not meant to become part of the core application but are used to explore and test new features.
TestA module, whose primary purpose is to test other modules.
FacadeModule which wraps one or more Third-Party modules and simplifies, abstracts and standardizes the interaction with these module.
DomainModule providing logic for a particular domain.