Open lhaze opened 4 years ago
lhaze
commented
4 years ago MODULES give people two views of the model. You can:
- look at detail within a MODULE without being overwhelmed by the whole,
- or they can look at relationships between MODULES in views that exclude interior detail.
Eric Evans, 2005
lhaze
commented
4 years ago 2.1 – Defining a Module
I’d like to say that a module is simply a “chunk of software.” Unfortunately, that doesn’t offer enough concision to differentiate a module from other software chunks, like objects, packages, services, or even applications. So we need to focus our definition a bit.
-- A software module is a deployable, manageable, natively reusable, composable, stateless unit of software that provides a concise interface to consumers.
That’s quite a mouthful (reminds me of the first definition of Java), and I feel badly about dumping this on us so early in a book that I had such high hopes for. But hopefully, after a bit of explanation, you’ll give me a second chance and keep on reading. We can illustrate this definition visually as shown in Figure 1. Let’s tease apart the definition.
2.1.1 – Deployable
Modules are a unit of deployment. Unlike other software entities such as classes and packages, a module is a discrete unit of deployment that can be deployed alongside other software modules. In this sense, modules represent something more physical than classes or packages, which are intangible software entities. Examples of deployable unis of software include EAR, WAR, and JAR files.
2.1.2 – Manageable
Modules are a unit of management. In the presence of a runtime module system, software modules can be installed, uninstalled, and refreshed. During development, partitioning a system into modules helps ease a number of otherwise complicated activities. This includes improving build efficiency, allowing developers to independently develop autonomous modules, and plan the development effort along module boundaries. Examples of software entities that comply with this segment of the definition include EAR, WAR, and JAR files.
2.1.3 – Testable
A module is a unit of testability. Like a class can be independently tested using test driven development, a module can be independently tested as well. Examples of software entities that comply with this segment of the definition include classes, packages, and JAR files.
2.1.4 – Natively Reusable
Modules are a unit of intra-process reuse. Unlike applications or services, modules are not a distributed computing technology, though SOA principles can be used to design software modules. Instead, modularity are a way to organize units of deployment in a way that they can be reused across applications, but a module is always invoked natively. That is, the operations exposed by a module are invoked by calling the method directly.
The way we reuse modules is also different than how we reuse services. Typically, a service is deployed only a single time and invoked by multiple consumers. Because modules are used intra-process, a modules is deployed with each process that intends to reuse its functionality. Examples of software entities that comply with this segment of the definition include classes, packages, and JAR files.
2.1.5 – Composable
Modules are a unit of composition. Modules can be composed of other modules. Typically, this involves coarse-grained modules being a composition of finer-grained modules.
2.1.6 – Stateless
Modules are stateless. There exists only a single instance of a specific version of a module. We don’t instantiate software modules, though we do instantiate instances of the classes within software modules, and these classes may maintain state. However, the module itself does not. Examples of software entities that adhere to this segment of the definition include WAR, EAR, and JAR files.
-- Kirk Knoernschild, Java Application Architecture: Modularity Patterns with Examples Using OSGi, 2012
The Module Pattern embodies the Modularity -- the Design Principle that promotes meaningful separation of contexts of the code.
Developers lean making some kind of modules or packages very early on their coding paths. Even though, many trend to build their module system around the structure of their most common framework or provided infrastructure. Let's recall that good architecture should promote reflecting business terms in the code.