At Devoxx last year I attended half a session by Kirk Knoernschild. I don't know why I missed half the session, but I fixed that by listening to the full talk over at parleys (not sure if you can see the full talk with out registering).

I found the talk intriguing for two reasons. First Kirk looks so much like me that I think I'm seeing me when ever I see a picture of him. It is really unnerving. The other, more important one: He is arguing a similar point as I am.

One of his main messages is: As a responsible developer or an architect you must take care of modules and their dependencies.

While my point is: you should take care of packages and their dependency structure.

So I went and bought his book "Java Application Architecture" in order to learn more about what he has to say.

It turned out to be a book that every advanced developer or architect should read. A label that I haven't attached to a book for quite some time. Why?

It covers the benefits and costs of a modular software architecture in great detail, something that I haven't seen in another book. Other books describe how to write code on a very granular level, like methods, classes and patterns. Or they describe the large scale structures relevant in system architecture, but the middle ground of packages and modules gets ignored by most books I have seen so far.

After the general analysis of the effects of modularity, the middle part describes patterns of module dependencies. I personally found this part a little boring and repetitive, because I apply these kind of pattern for quite some time now. But I think it would be very helpful for others who want to apply the tool of modularization to their application.

In the last part Kirk describes how OSGI helps in achieving modularity and reaping the benefits of it. I found this part interesting again, because so far I've experienced OSGI only as a road block to productivity and this part together with the rest of the book explained how it actually could have helped me.

Of course the book isn't perfect either. I think it is to repetitive, which made me skip some passages. Also the title is a little misleading, since it talks only about a very specific part of application architecture. But none of this should keep anybody from buying and reading this book.