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

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

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s