At least the first two parts: “The Case for Modularity†and “The Patterns†should be known by heart by any Java developer. It should be second nature for disciplined and professional developers.
In “The Case for Modularity†Kirk goes over the definition of what a module is, whether architecture is a phase carved in stone in the beginning of a project, or whether it is pervasive and should be attended to all the time.
How growing complexity must be countered by disciplined maintenance.
Why Technical Debt and Design Rot must be cleared to keep the source code from succumbing to the development death spiral.
Why cyclic dependencies must be rooted at all costs.
And what the benefits of modular structures are.
While you may think that a given piece of software is not ripe for modular extraction, because it will never be replaced or reused elsewhere. This is not the right attitude, as the first or second use of the source code is the test cases preferably developed in sync with the source code, either in a TDD or BDD way. It is simply easier to unit test a unit, no matter how big that unit is.
Finally – just to prove that this is not hot air preached from the pulpit – Kirk refactors a small application in 7 steps each a tiny isolated step improving on the overall structure. This is how software should evolve once it has fallen prey to design rot.
The second part of the book, The Patterns, describes 18 patterns in 5 chapters, which Kirk has made available here:
The Base Patterns:
- Manage Relationships
- Module Reuse
- Cohesive Modules
Dependency Patterns:
- Acyclic Relationships
- Levelize Modules
- Physical Layers
- Container Independence
- Independent Deployment
Usability Patterns:
- Published Interface
- External Configuration
- Default Implementation
- Module Façade
Extensibility Patterns:
- Abstract Module
- Implementation Factory
- Separate Abstractions
Utility Patterns:
- Colocate Exceptions
- Levelize Build
- Test Module
The third part concludes with examples in OSGi, covering Java, Scala, and Groovy implementations.
The book is a must read and must understand for (Java) developers and architects.
I highly recommend the book for anyone interested in modularity, especially developers looking at an existing code base resembling a big ball of mud who wants to disentangle it.