Re: Deployable Units and Layers
Posted: Jan 14, 2005 9:11 PM
>>So, as a matter of fact, I would say that one deployment
>>unit is more maintainable than, for instance, ten.
One deployment unit is easier to deploy. It is not easier to maintain because you are not as aware of the ramifications of change if everything is bundled together.
>>So presenting only one unit to the user is better than
>>presenting one unit for each layer and thus making the
>>user aware of the layering design.
Users don't care about the layering design, whether it be a single unit or multiple. They care about how quickly you can make changes correctly, and then deliver those changes.
>>...principle: if several deployment units are always
>>present together and in the same combination of versions
>>in all the deployments, then they should be merged into
Today, I'm developing mostly Java web applications. With Java web apps, you'll still only deploy a single .war or .ear file that contains your .jar files. It's nice to know that if your app is composed of 10 different .jars, and you only change 1, when a new bug surfaces you'll know in which .jar file the bug exists. The smaller the unit, the easier (and safer) it will be to maintain. There's no doubt about that. And while you may believe today that the same combination of versions are used in all the deployments, it may not be that way tomorrow. Instead, just assemble your application from the appropriate version of separately deployable units (if they never change, then so be it). The user winds up with the same thing, and the developer winds up with something that is more manageable, flexible, and maintainable.
Even back when I was developing mostly client/server applications, where we would deploy a single executable with multiple other libraries, keeping these libraries small and focused was very useful. It helped promote the "ilities", and we took a great deal of comfort in knowing that when we patched one of these smaller libraries, we were only deploying the minimal amount necessary. If a problem surfaced after the deploy, we'd know the problem was due to the new version of the library. Had we deployed one huge unit, we could not be certain that was the case. Additionally, we'd be required to deploy that one huge unit for even the smallest of changes.