Modular Architecture

Patterns of Modular Architecture

Module Reuse

Statement
Emphasize reuse at the module level.
Description
One of the oft cited benefits of object oriented development is reuse. Mostly, we’ve failed miserably in achieving any degree of reuse that is directly attributable to objects. A large part of this failure is very likely because using objects does not guarantee reuse, but actually requires a significant amount [...]

Acyclic Relationships

Statement
Module relationships should be uni-directional.
Description
When you define a relationship between two system components, their coupling is increased. Some degree of  coupling is a necessary simply because components need to work together with each other to accomplish some task. But certain types of coupling should be avoided. The diagram at right in Figure 1 illustrates a [...]

Manage Relationships

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 module, M1, we can say that M1 has a Physical Dependency on M2. [JOUP02]
In Figure 1, [...]

Chapter 7 – Reference Implementation

Thus far, we’ve spent the majority of Part 1 making the case for modularity. Before we delve too deeply into the patterns, let’s witness first-hand the benefits of a modular architecture.
7.1 – Why No OSGi?
The example that follows doesn’t use OSGi. One would think that if I’m going to modularize my system, I’d want to [...]

Chapter 6 – Realizing Reuse

Reuse is software development’s unattainable panacea. The ability to compose systems from reusable elements has long been our achille’s heel.  We want reuse so badly, yet our failures are spectacular. Almost all major technology trends of the past 20 years touts reuse as the saving grace. Vendors have sold billions of dollars in software through [...]

Chapter 5 – Taming the Beast

Modularity is not a new concept. In his 1972 paper titled, “On the Criteria to be used in Decomposing Systems Into Modules”, David Parnas cited the work of Gouthier and Pont as the first lucid statement of modular programming:
A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program [...]

Chapter 4 – Architecture and Modularity

Modularity plays an important role in software architecture. It fills a gap that has existed since we began develop enterprise software systems in Java. Here, we’ll discuss that gap and explore how modularity is an important intermediary technology that fills the gap.
4.1 – Defining Architecture
There are numerous definitions of architecture. But within each lies a [...]

Chapter 3 – The Two Facets of Modularity

There are two aspects to modularity – the runtime model and the development model. Today, emphasis is on the runtime model, with frameworks emerging that provide runtime support for modularity. But eventually, as the runtime model gains adoption, the importance of the development model will take center stage. The patterns in this book focus on [...]