Enterprise Integration Zone is brought to you in partnership with:

Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 86 posts at DZone. You can read more from them at their website. View Full User Profile

Java Application Architecture

04.03.2013
| 8986 views |
  • submit to reddit

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.

 

Published at DZone with permission of Jens Schauder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)