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 [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Emphasize reuse at the module level.
Description
One of the oft cited benefits of object oriented development is reuse. A large part of its failure is because classes aren’t the best reuse mechanism.
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Module relationships should be uni-directional.
Description
When you define a relationship between two system modules, their coupling is increased. Some degree of coupling is necessary simply because modules need to work together to accomplish some task. But certain types of coupling [...]
For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.
Statement
Design module relationships.
Description
A relationship between two modules exists when a class within one module imports at least a single class within another module. In other words:
If changing the contents of a module, M2, may impact the contents of another [...]