Object-oriented applications above some level of complexity are almost always modelled as a layered architecture. While the typical three-layer architecture remains the most widely known, n-layer architecture is also often utilized. Here's a typical design almost anyone can create (in Visio or Power Point, that is):
There seems to be an almost universal agreement that layering is the correct things to do, but do you know why layering is considered such an attractive design feature?
When I ask this question of people, most answer that this enables them to replace a certain implementation with another implementation. What's even more interesting is that the typical implementation of this design is best illustrated like this:
No clear separation of logic is implemented, modules tend to trample over each others' domains, but worst of all, there's a strong hierarchy of dependencies in place: Most assemblies have dependencies on other assemblies in the solution, and few of of the projects can be compiled without also compiling all the dependent projects. The only projects that can typically compiled without volatile dependencies are the ones in the bottom layer, but those are the ones you most need to be independent of.
When confronted with this fact, most project members don't think this is a big deal, since the ability to replace one implementation with another isn't important in their current project. To paraphrase a typical response: "Yes, it would be nice to be able to replace our relational database with XML files without recompiling, but we are never going to need this, so why bother?"
This attitude suggests to me that people are missing the point.
The reason why layering is important is because each module must be able to exist in isolation. This means that it should be possible to compile a project without having to load any other projects containing volatile dependencies. If you ever find that you have to load 35 projects into your solution to compile a single project, you are doing something wrong. Ideally, you should be able to define a self-contained solution containing a small subset of your projects; about five projects, and certainly no more than ten.
If the ability to replace one implementation with another is not the sole reason for isolation, then what is?
Personally, I can think of at least three independent reasons:
If just a single of these reasons seems valuable to you, isolation should be one of your top priorities as you are implementing your design.