For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Module behavior should serve a singular purpose.
Description
There are two key elements that affect module cohesion. These follow:
The rate at which the software entities within a module change.
The likelihood that the software entities within a module are reused together.
Based on [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Use factories to create a modules implementation classes.
Description
One of the challenges we face with Abstract Modules is how the object relationships are established at runtime. A class dependent on an abstraction should avoid referencing any of the implementing classes, [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Place abstractions and the classes that implement them in separate modules.
Description
You create an abstract class or interface to help reduce coupling between classes. This offers the ability to create new implementations of the abstraction without impacting clients dependent on [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Depend upon the abstract elements of a module.
Description
Modules heavily depended upon have many incoming dependencies. In other words, you may have many modules that all depend on a single module. On one hand, this is a good thing because [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Each module should have a corresponding test module.
Description
Writing tests is one of the most important activities you should perform as a developer. Create a robust suite of tests has significant advantages, both long and short term. Short term, tests [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Perform the build in accordance with module levelization.
Description
An automated and repeatable build is a critical aspect to most successful development projects. First and foremost, an automated and repeatable build forces you to integrate early and integrate often, so you’re [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Make a modules published interface well-known.
Description
A modules’s PublishedInterface is the set of public methods on the public classes within the module that you expect developers using the module to invoke and work with. A PublishedInterface is subtly different from [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Modules should be as independently deployable as possible.
Description
For a module to be independently deployable, it cannot have any outgoing dependencies on any other module.
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Module relationships must not violate logical layer relationships.
Description
It’s common knowledge that when designing systems of any degree of complexity, the presentation, business logic, and data access should be separated into distinct layers. There are several important considerations when [...]