In this article, we’ll see the difference between two prevalent terms in Computer Science that are often mistakenly interchanged: Layers and Tiers.
The term layer refers to a logical separation of code. In other words, it’s a coherent set of related functionality.
Structuring applications in layers is a way to organize our codebase better. For this reason, portability and maintainability are drivers that push us to use this kind of structure.
Indeed, we find an application of this concept in various types of architecture, such as Layered Architecture and Hexagonal Architecture.
As an example, the following is a representation of a layered architecture:
Here, the User Interface Layer, Business Logic Layer, and Data Access Layer each have their own responsibility and are logically separated.
Layers have nothing to do with their physical separation. When we talk about layers, we don’t specify where we’ll deploy them.
On the other hand, the term tier refers to the physical structure. Tiers define where to deploy the layers, without necessarily a one-to-one mapping. So when we talk of an application’s tiers, we mean its topology.
As an example, let’s see how we can physically divide the layered application of the previous paragraph:
Above, we see a representation of an n-tier Architecture where each tier physically hosts a layer. This is the classic 3-tier Architecture.
Tiers are defined with an eye toward the computing environment on which the software will run. By dividing an application into tiers, it’s possible to achieve a higher degree of scalability.
We can also deploy the same layers of our application with a different tier structure:
In this 2-tier, or Client-Server Architecture, the UI Layer is on a dedicated tier while the Business Logic Layer and Data Access Layer are on another.
In this article, we defined the concepts of Layer and Tier and how these map to logical and physical architecture.