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
Type | Description |
Interface-Module | Contains only interface definitions. They can only depend on other Interface-Modules. |
Plain-Module | Module does not depend on any other modules. |
Proxy-Module | Module works as a facade to the functionality of other modules. But modules does not add much additional functionality. |
Application-Module | Module, which uses other modules and adds its own functionality. |
Included-Module | Module, which must be executed inside another module. |
XPlain-Module | Plain modules, which only depends on Interface modules. |
Module-Execution-Environment | This is not really a module but the framework, which provides the execution environment for the modules |
Module-Launcher | This 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
Type | Description |
Utility | A module which provides simple but many functions, which are used by many other modules. |
Extension | A 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-Party | A 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. |
Playground | Modules which are not meant to become part of the core application but are used to explore and test new features. |
Test | A module, whose primary purpose is to test other modules. |
Facade | Module which wraps one or more Third-Party modules and simplifies, abstracts and standardizes the interaction with these module. |
Domain | Module providing logic for a particular domain. |