I know what you're thinking: well duh! And yet often the distinction gets lost somewhere between design of the software and deployment topology.
Layering is an important technique that allows to manage complexity, increase cohesion of the components and to isolate inevitable changes from impacting rest of the system.
Tiers usually refer to the deployment structure of the systems. Tiers are separated from each other for various operational and security reasons. My point is that multiple layers can often be deployed into the same application tier and should not be equated with them.
A lot of the misconception, at least in Java world, comes from the traditional JEE stack: presentation layer, business layer, DB layer. Those are valid distinctions that should exist at the code level, but not necessarily in deployment. For example, it often makes sense to deploy presentation layer and business layer together for the sake of performance.
The standard deployment topology looks something like this:
But sometimes there is not need to separate Presentation Layer from Business Layer into different deployment tiers. Combining them allows us to avoid overhead of serializing and transporting data between the tiers. So the resulting topology would look like this:
Furthermore, sometimes it even makes sense to access DB directly from presentation layer, entirely skipping the business layer for fast reads of DB data. This does not mean having SQL code mixed in the pages, it just means that data extraction does not need to be done in fat EJB-like components. It can come straight from DB views and be wrapped by a light data access layer used by the MVC controllers. This might sound like a heresy but do we really need this useless layer of empty services that just pass data from DB to presentation?
Of course “writes” need to be processed by the business components and have all business rules applied before landing in DB. Updates are usually done on a per-object level and benefit from rich domain model. But “reads” often just need highly optimized and joined data from DB, especially if it’s a read-only data.
For all these reasons it’s important to distinguish layers from tiers. Multiple layers can be combined into the same deployment tier and sometimes even have some of the layers skipped.
