It is common for programmers to design systems as a set of layers. (For example, see FourLayerArchitecture, RelationalDatabaseAccessLayer, IsolationLayer.) However, the layering often exists only in the original programmer's mind, and is not reflected in the source code. A common case is that after Programmer A finishes a system, Programmer B comes along to add some features, is unaware of the layered architecture, and proceeds to turn the system into a BigBallOfMud.
We could just conclude that Programmer B is incompetent, but there is a real problem here. Programming languages generally don't provide any abstractions that indicate layer dependencies. One can use other language features to hint at layering (for example, PackagePerLayer), but unless Programmer A explicitly documented the layer scheme somewhere, any other programmer is unlikely to understand what Programmer A was thinking or how to maintain the layer separation as new features are added.
Are there patterns or conventions that people have found helpful for communicating information about layering, other than those big static unmaintainable design documents that we never have time to write or to read?
Separate the layers into distinct projects. Each layer could be a library, a COM object, an executable; but ensure each layer builds to a separate binary through a separate process that your development environment treats as a separate entity. Then NarrowTheInterface between the layers so much so that it's simple to communicate from one layer to another (if you can't, the separation is invalid). Use the FacadePattern to talk between layers to limit the interaction, or by using pipes, or event queues, etc. Once again, care must be taken that the interaction mechanism doesn't become too complicated. For example, the pipe server's complexity should not become a concern. Again, this typically indicates an invalid separation. Then again, the communication complexity may be the impetus to separate layers. Think of a journaling file system. -- SunirShah