I had to stop and think about that one myself. But it makes sence, at least if you emphasize on "hint at". When you wander though the source code, cascading the

I had to stop and think about that one myself. But it makes sence, at least if you emphasize on "hint at". When you wander though the source code, cascading the layers of abstraction, and jumping from place to place, it's nice that the code is somewhat bound to the same context.. in a way. It could be naming conventions, and using the same names for the same things consistently throughout the code. Another way to hint at the overall design is strict structure, e.g. layers: DAO-layer handles persistence, Business-layer handles business, Service-layer handles the interfaces to other parts of the application / other applications, etc. Naming the code-artifacts accordingly hints strongly at what it's doing. Also code that is not directly dependant on the context (business domain) should be put in a special place, in Java that would be in util-methods "hidden" away in some common-package. This way it does not clutter the rest of the code, and allows for easier reuse.