Layering is a pattern that must be applied judiciously. Not that any pattern can be applied mindlessly, but layer specifically can cause major problems if not called for.
With the right circumstances, however, layering can help a system withstand the test of time. As access to apps on mobile devices proliferate, layered applications will benefit greatly, as they may be able to change the top one or two layers in a stack to support the new UI and communications semantics, hopefully leaving a majority of the system untouched.
I can't recall if it was in one of our readings, but a quote stands out in my mind to the effect of "show me a team boundary, and i'll show you a software boundary", in that the organization of teams tends to naturally dictate the separation of software. Layering works great for this, because you can divide up a project into a bunch of layers that *should* have boundaries, and exploit this behavior rather than suffer from it. I think that this is an interesting consideration to make while designing a layered architecture.
Most applications have some form of natural layering, regardless of whether they use the formal definition thereof. Refactoring an application to use an explicitly stated layered architecture can take on radically different forms. In application with excellent separation of concerns and modularization, adding layering may be as simple as uncovering the communications pathways, and more strictly defining the interfaces involved. In more poorly designed applications, where spaghetti code and dubious design practices are present, layering would probably best be left for the inevitable redesign/recode, though analysis of the existing code and lessons learned therein would surely shed light upon a likely layer decomposition.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment