December 10, 2007
Socks Go In The Sock Draw (And Other Approaches To Package Architecture)I've noticed a couple of distinct approaches to package architecture on my many and varied travails.
There's the "Socks Go In The Sock Draw" approach, where we package similar kinds of classes together (e.g., domain objects go in the domain layer, data access classes go in the data layer, and so on). This often seems to be based on convention (or "standards", which are just conventions for people who walk around with a row of biros sticking out of the top pocket of their short-sleeved nylon shirts).
There's another apporach which is the "Woollen Socks Go With Winter Shoes" approach, where we package together classes that are used together.
The first approach tends to have cognitive advantages because it makes classes easier to find. The second approach tends to lead to packages that are more highly cohesive and more loosely coupled, since things that depend on each other tend to be lumped together.
Both advantages are important to the maintainability of our code, and so the real art to package design is to balance these - and other - approaches so that we have packages that are cohesive and loosely coupled, but not so much so that it's difficult to find things.
Most importantly, though, I strongly recommend that you optimise your package architecture for what it is, and not for what you think it might be at some point in the future. Why, for example, might you think you need a UI package, a Process package, a Services package, a Domain package and a Persistence package when you've only written five classes? Let your package architecture evolve with your code and make it the best it can be for the code you've actually written.
There is a third approach, of course: which is that all clothes go in a pile on the bedroom floor. Veterans of client/server database applications may recognise this style of package architecture...
Posted 13 years, 3 months ago on December 10, 2007