December 18, 2007
Schools of Package Architecture - An IllustrationWhile I'm about it, I wanted to illustrate what I meant when I proposed two common schools of package architecture; namely the socks go in the sock draw school and the woollen socks go with winter shoes school.
Many of you may recognise this style of packaging, for example. It's a fairly typical mulit-tier architecture, much vaunted by vendors and pundits alike.
The traditional n-tier architecture packages like classes together
The decision as to what classes go into what packages in this school of package design is largely determined by the type of object. If it's a UI component, for example, then it belongs in the UI package. If it's a business object, then it belongs in the "business" package. And so on.
The advantage of this style of packaging is that I know where to look for a particular kind of class. The disadvantage is that it tends to lead to packages that are less cohesive (less classes in the packages depend on each other) and more tightly coupled (more classes depend on classes in other packages).
A much less practiced approach is to package classes together because they're used together, so the same classes could be packaged like this:
Package architecture where more interdependent classes of different types are packaged together
The advantage of this style of package design is that it will tend to localise the propagation of changes to fewer packages, lowering the potential cost of change for the software as a whole. But in large systems, it can make it hearder to find classes of a particular type. (In this example, though, I suspect it would be no harder.)
It also doesn't allow for a clean separation of concerns between distinct architectural responsibilities (namely, display logic, control logic, business logic and persistence). Though I would argue that with many implementations of the traditional n-tier package structure I've come across, that separation of concerns is an illusion. But that's usually because of a failure to exploit abstractions and create genuine dependency inversions between classes in each layer. Which is a whole other can of worms...
To round off, then, I would urge you to be mindful of leaning to far towards either school of package architecture. Don't just mindlessly put socks in the sock draw and pants in the pants draw, but don't be 100% driven by package coupling and cohesion to make those decisions, either. The real skill is finding the right balance, and creating packages that make stuff easier to find but are as cohesive and loosely coupled as you can make them at the same time.
Failing that, just split your code 50/50 between GUI event handlers (or HTPP request handlers) and SQL stored procedures. Hey, it worked a treat back in the 90's, didn't it?
Posted 10 hours, 10 minutes ago on December 18, 2007