By the name, you can tell that the idea is using ‘tiers’ to separate a project into different layers in order to create a project environment where work on different tiers is essentially independent, as long at the integration between stays functional. Let’s start off with a relatively simple diagram to help picture what this is about:

Overview of a three-tier application vectorVersion.svg
By Bartledan (talk), based on a file by User:Foofy – I created this work based on en:File:Overview_of_a_three-tier_application.png, Public Domain, https://commons.wikimedia.org/w/index.php?curid=6907222

Now, though the image and common practice separates the tiers into 3, the Data, Logic and Presentation tiers… this is by no means a rule. As the name suggests, any number of tiers can be ring-fenced for a number of reasons, here just a few:

  • Logical separation of units to allow an almost encapsulation feel but to allow independence from each other
  • Separating tiers with regard to architectures and possibly expected life-cycles (for example splitting the logic tier into technologies which will and will not be upgraded often)
  • Building tiers for physical separation, so having the data, the logic and the presentation tiers each on their own servers/clusters

On a .Net front, a great way to learn, for me especially, is to just do it so here is a wonderful walk-through in setting up a 4 tier data application in Visual Studio. Though very simplistic, it shows you clearly how you can separate a solution into practically separated projects, each of which can be worked on independently.

The above image is from the Wikipedia page which gives a great overview of it uses and origin. For a more practical perspective, here is the overview on MSDN and the first two paragraphs give a great summary as well.