Sponsored Link •
Layering is a powerful architectural pattern. It can be more powerful when using your deployable units as layer boundaries.
On a recent Fowler blog, he introduces a vote that occurred on some layering principles that he and a group of others identified while attending a conference. As he mentions, the list is hardly definitive, but interesting nonetheless given the convincing number of votes received by some of the principles. Here's a partial list of those principles with a difference greater than five on either the positive or negative side (the voting style used was to give everyone 10 positive/10 negative votes):
Most of these don't necessarily surprise me, and the majority of them are simply good practice that most everyone is already aware of.
There were a few interesting votes, however. I think they hit the nail square in recognizing that separating development teams by layer doesn't work as well as when separating by use case or functional area. And I've never actually heard of anyone distributing at layer boundaries, but I don't suspect it would work to well.
However, the one vote that surprised me most was the number of negative votes received (along with zero positive votes) by Layers should have separate deployment units. If we really feel so strongly about low coupling and high cohesion, a strong separation of concerns, no circular references, and independently testable layers, then isn't separating your layers into independently deployable units a great way to approach, and help enforce, each of these?
I don't think it's necessarily important that each layer be a single deployable unit, but instead that multiple layers not reside in a single deployable unit. By not separating your layers into deployable units, can you be certain your layers are independently testable? Can you guarantee that there are no cyclic references? Certainly tools such as JDepend are available to help, but separating layers into deployable units is equally, if not more powerful, and opens up other windows of opportunity as well.
|Kirk Knoernschild is a hands-on software consultant with over ten years of industry experience, and is passionate about using leading best practices to build better software. Kirk is the author Java Design: Objects, UML, and Process, published in 2002 by Addison-Wesley. He frequently contributes to various technical publications, and actively updates his personal website, www.kirkk.com, with new articles and whitepapers on a variety of software development topics. He is also the founder of www.extensiblejava.com, a growing resource of design pattern heuristics in Java.|