Architectural Pattern: Layers




After collecting requirements from customers, we have to define the architecture of the system

So, we need to find a high-level subdivision of the system into constituent parts

Need to orgainize the mess into a workable structure

We will introduce the Layers pattern to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction




Networking protocols is the best known

The International Standardization Organization (ISO) defined the following architectural model, the OSI 7-Layer Model

Application Layer 7 Provides misc protocols for common activities (ftp, telnet, http, etc)
Presentation Layer 6 Structures information and attaches semantics
Session Layer 5 Provides dialog control and synchronization facilities
Transport Layer 4 Breaks messages into packets and guarantee delivery
Network Layer 3 Select a route from sender to receiver
Data Link Layer 2 Detects and corrects errors in bit sequences
Physical Layer 1 Transmits bits: velocity, bit-code, connection, etc


Layered approach is considered better practice, since different issues separately reaps several benefits

For example, development by team, support incremental coding, testing

Rewriting can be down on a certain layer only




A large system that require decomposition




The system we are building is divided by mix of low and high level issues, where high-level operations reply on the lower-level ones

For example, high-level will be interactive to user and low-level will be concerned with hardware implementation

So, we need to balance the following requirements:




Structure your system into an appropriate number of layers and place them on top of each other

The lowest layer is called Layer 1 ... Layer J-1, Layer J ... the highest is called Layer N

Most of the services that Layer J provides are composed of services provided by Layer J - 1.

Thus, the services of each layer implement a strategy for combining the services of the layer below in a meaningful way. (Whether you would like exception of not depends on the system you build)




  • Layer J


  • Provides services used by Layer J+1
  • Delegates subtasks to Layer J-1


  • Layer J-1


Services of Layer J only used by Layer J+1 - there are no further direct dependencies between layers

The following represents a high conceptual view of Layers:

Client ---------- uses -----------------  Layer N
                                          Layer N-1
                                          Layer 1


In more detail, it might look something like this:

Layer 3 --- Component 3.1 --- Component 3.2 ---- Component 3.3
             ||              |              ||
             ||              |--------------||
Layer 2 --- Component 2.1 --- Component 2.2 <--> Component 2.3
             ||              |              ||
             |---------------|              ||
Layer 1 --- Component 1.1 --- Component 1.2 ---- Component 1.3



Dynamics / Scenario

Scenario I (Client called to Layer N)

Client issues a request to Layer N

Layer N cannot carry out, so it calls to Layer N-1 for services

Layer N - 1 sends requests to Layer N - 2

... Layer 2 sends requests to Layer 1

Services finally get performed in Layer 1

Replies passed back up from Layer 1 to Layer 2 ...

Replies passed back up from Layer N -2 to Layer N - 1

Reply passed back up from Layer N - 1 to Layer N

(Single request might get mapped to mulitple requests when going to lower layers)


Scenario II (Bottom-up communication)

A chain of actions starts at Layer 1 (a device driver detects input ...)

Inputs are translated into an internal format for Layer 2

... go to Layer 3,4,5 and so on ...

A "response" are detected in Layer N

(Called notifications)

(Scenario I is fan out, Scenario II is either remain 1:1 or condensed into a single notification)


Scenario III (Requests only travel through a subset of the layers from top to bottom)

Request to Layer N

Layer N calls Layer N-1 for services then "stop"

(Layer like this have to maintain state information / control info)

(Caching is one example of this scenario)


Scenario IV (Requests only travel through a subset of the layers from bottom to top)

An event is detected in Layer 1

Replies to Layer 2, then Layer 3, then "stop"

(Layer 3 probably has checking in place to look for repeated request from lower layers)


Scenario V (Communicate with 2 stacks)





Define the abstraction criterion

Common Layers Principles

Determine the number of abstraction levels

Name the layers and assign tasks to each of them

Specify the services

Refine the layering

Specify an interface for each layer

Structure individual layers

Specify the communication between adjacent layers

Decouple adjacent layer

(For example, upper layers know lower layers, but not vice versa)

(Higher layers register callback and still maintain upper layer hidden)

(Could relax some constraint for performance)

Design an error-handling strategy




Relaxed Layerd System

Layering Through Inheritance

Shared Component for some Layers



Known Uses



AS/400 MI


Windows NT with Relaxed Layered system






Reuse of Layers

Support for standardization - dependencies are kept local



Cascades of changing behavior when behavior of a layer changes ... e.g. lower layer output increase 100x

Lower efficiency

Unnecessary work

Difficulty of establishing the correct granularity of layers