Pattern Analysis/Layers

Summary

Layers is a classic architectural pattern for 'application architectures'. That is, Layers is normally thought of as a build-time strucuturing technique for building an application or service that will execute in a single process.

The problem is that there are many variations on the layers pattern. For example, the following patterns all involve using layers in software architecture:

• Four-layer architecture (analysis)
• Layered and sectioned architecture(http://c2.com/ppr/envy/#well_encapsulated_code)
• Layered architecture
• Layers (from POSA1)
• Patterns for generating a layered architecture
• Relational database access layer (http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Performance/performance.htm)
• Secure access layer (analysis)

Martin Fowler also discusses layers: http://martinfowler.com/isa/layers.html

Analysis

One huge problem with all of this is that no one agrees exactly on what a 'layer' is. For example, some layering schemes have very little relationship to the runtime. Others confuse layers with a 'tiered' runtime architecture where the various layers are not only split by build-time packaging, but by running in different processes and possibly different nodes at run time.

So in this work we want to clearly separate the idea of a 'tiers' from a 'layers'. A tier is a structure for runtime component interaction that implies nothing about the construction of the build time. For example, we might have a 3 tier system composed of a web browser, web server/asp pages, and database. Each tier runs in a different process and in many systems different nodes. In this case, the majority of the component are off the shelf and only the asp pages are part of the application.

Reference