Buzzword {Non}Compliant
Deployable Units and Layers
by Kirk Knoernschild
January 11, 2005

Summary
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):

Low coupling between layers, high cohesion within them. 10/0

Separation of concerns. 11/0

User interface modules should contain no business logic. 10/0

Business logic layers contain no user interface and don't refer to user interface modules. 8/0

No circular references between layers. 8/0

There are at least three main layer types: presentation, domain, and data source. 3/9

Business layer only uses abstractions of technological services. 14/0

Separate development teams by layer. 1/22

Layers should be testable individual. 12/0

Distribute at layer boundaries. 0/18

Layers are a logical artifact that does not imply distribution between layers. 11/0

Lower layers should not depend on upper layers. 6/0

Layers should be shy about their internals. 8/0

Rethrow exceptions at layer boundaries. 0/15

Layers should have separate deployment units (eg separate jars or assemblies for each layer). 0/7

Layers may share infrastructural aspects (eg security). 7/0

Inbound external interface modules (eg web service handlers) should not contain business logic. 10/0

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.

Talk Back!

Have an opinion? Readers have already posted 15 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Kirk Knoernschild adds a new entry to his weblog, subscribe to his RSS feed.

Digg |

del.icio.us |

About the Blogger

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.


	Web Artima.com