When discussing layering, there's often some confusion over the terms layer and tier. Often the two are used as synonyms, but most people see tier as implementing a physical layer.
- "Patterns of enterprise application architecture" By Martin Fowler. Page No: 19. ISBN: 978-81-317-9402-9
While discussing with a collage mate I found out that the confusion about the "tiered" architecture of the application and the "layered" architecture of the application really needs to be cleared up. So this post is here to make the things clearer. Those already know what the difference is can ignore this post; this post is intended for those who do not understand it well. (However this will not teach you how you should design your layers/tiers; instead it shows the difference)
But before going into the question of layer and tier we need to ask a fundamental question: why tier and layer are required ?
And the answer could be to reduce complexity, increase re-usability, or for standardization etc.
In both the terminologies, they divide the code in different parts like "presentation","domain logic","data source logic"(or even more parts sometimes).
In really simple application one might have one method(i use the term method to indicate a group of callable statement, it might be a function, subroutine etc in context of any other c like language). One might be to get data, second could be for domain logic and third could be for view. But as the application becomes more and more complex you will be required to separate them through some mechanism. In the next iteration of development you might move those methods to different classes. And if the application is even more complex, you might put those classes in different package,or namespace or any other mechanism to separate them.
If it is a java application you might create separate classes, put them in one jar and use them in the upper level abstractions. If you are working on a .Net project you might create a dll in same way. If you are working in some other language there would be some mechanism to achieve the same thing.
Typically one would create a package(or dll or jar) for data source logic (that is for accessing data from the data source - typically it would abstract the data access to higher level layers. the higher level layers should not know from where the data is coming from. you might be able to change the data source from file to relational database and from that to non-relational database without higher level knowing about the change. You get such advantages when designing an application with layering in mind.). You would use the data source logic in the domain logic. And then further use the domain logic in the presentation. What you would be doing is much like shown in the Fig-1 below:
 |
What we are doing here in Fig-1 is logical separation of code. Although you would have programmed the code in different method, different class, different package, different project; at its heart all the code would be running on the same machine. When the code is running on the same machine as shown in the above fig it is known as "layering".
But sometimes because of some issues the layering of the application does not help, you need to make pieces of you application and put them on different machines to solve those issues. When you put those pieces (e.g., presentation, data source logic and domain logic etc or even more pieces) on different machines, they would communicate with each other over the network in order to complete some activity.
The communication could happen by simply accessing a restful URL, or calling a web-service or calling a WCF service of RMI or any other technology. Typically when you say the architecture is "tiered", the 'pieces' would typically be on different physical(or logical) machine.
 |
| Fig - 2 |
When ever you apply tired architecture, it greatly affects the over all performance when compared with the layered architecture because the communication between two physical machines is always slower than the communication between two pieces on the same machine.
Although one tier itself can have many layers in it.
To conclude we can say that even if you have used methods to separate view, domain model etc; you can call it a layered architecture. Layered architecture is on same machine. Tiered architecture is always on different machine (although you can put them on same machine if you wish).
There are many points that affect the decision abut layered architecture and tiered architecture so a trainee or journey man should never take decision directly. He/She should always consult the "master craftsman" before taking any decision.
