Home > Architecture > Layers vs. Tiers

Layers vs. Tiers

Most people often use the terms layers and tiers interchangeably. A layer is a logical means of separation of concerns. A tier is a physical separation. Even when we run all the layers of a layered application on a single machine, it will still be n-layered. Provided the resource requirements are met the application would still run without any major issues.

While you can collapse deployment to make all the layers run on the same node (provided the resource requirements are met) It will be hard to do the other way round. It will often be difficult to introduce a tier boundary between two layers when the tier boundaries were not designed for. Most applications today can handle introducing tier boundaries between the database and data access layer. To introduce a tier boundary other than this you have to design your application explicitly for it. Example: Tier boundary between presentation layer and the service layer / application layer is the most used one. But this has to be explicitly designed for. The remote interfaces should be coarse grained as opposed to fine grained to take into account the network latency / inter-process latency involved.

I have not seen a tier separation between the Business Layer / Domain Layer and the Data Access Layer though this might become more common with the cloud based data services looming over the horizon.

To those who had seen the client server era, another common trend in the recent past is the disappearance of the app server. The web server typically hosts the domain logic in its own process leading to the popularity of two tier application (if you do not consider the browser machine separately). This is a reasonable optimization considering that presentation related logic is already running on a central server (the web server). But once applications are written for this assumption it becomes really difficult to introduce a tier boundary.

A typical two tier web app will have the following layers.

Presentation –> Domain –> Data Access (all running on web server) => database.

-> Logical separation

=> Physical separation

Since the object-oriented domain layer interfaces are fine-grained it will be difficult to introduce the tier boundary later without rewriting the presentation layer. A different approach would be

Presentation –> Service –> Domain –> Data Access (all running on web server) => database.

The Service layer offers a coarse-grained interface to the presentation layer thus making the optional tier boundary possible when really needed.

Presentation ( Web Server ) => Service –> Domain –> Data Access (App server) => database.

I have introduced several terms Presentation, Service/Application, Business/Domain, Data Access. Most of them are self explanatory. In case there is any confusion please refer to Martin Fowler’s Patterns of Enterprise Application Architecture catalog for the vocabulary used. I will also discuss this layering scheme of Fowler along with that of Eric Evans’ scheme in the near future.

Categories: Architecture
  1. No comments yet.
  1. November 19, 2010 at 11:01 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: