TTA – Three Tier Architecture

TTA describes a software solution that is logically divided into three layers or tears.

I could theorize about this subject all day long, discuss in depth the benefits it brings and advocate my full loyalty to it. But I’m not a theoretical person at all.
I would much rather use practical examples to explain my theories.



If we imagine what most applications are composed of

  • Some sort of user interface
    • Graphical user interface
    • Web services
      • REST
      • SOAP
      • etc…
  • Some sort of business logic in the background that dictates how the application works
  • Some sort of data source
    • Database
    • Web Service
    • Files
      • XML
      • TXT
      • etc…

Where to begin?

The main issue I find in all the projects I do is to get a grasp on where to begin. If you don’t know where you start you can never reach the finish, right?

Well, as in every application (and this translates into real life for me), I find the best starting point to be the Functional Requirements.

Functional requirements usually summarize what the client wants from the application.

Once we get to grips with what is needed from the app, the next step is to logically determine how to go about it. We do this through the creation of many different graphs and diagrams such as ER diagram and class diagram, use case just to name a few.

One of the main problems with applications, especially for larger ones, is the sheer number of files you end up with. This number can run into the thousands. So the main question when you get to this point is “Where did I put that piece of functionality?” and especially when changing functionality “Did I change this in all the correct places?”.

Why do we need to keep track of what file(s) have which functionality? We don’t!

The Tiers

We already said the tiers are a logical grouping of functionalities didn’t we?


Presentation Tier

The presentation tier usually includes the graphical user interface for your users. But what if your users aren’t human? I think, and always enforce, that the presentation tier includes the web services as well. Web services are in essence the user interface for non-human users, such as other applications.

Application Tier

The application tier, or Business Logic Tier as I like to call it, usually includes the business logic rules of your app. To us, they are usually comprised of three main components

  • Entities
    • Entities are logical representations of objects or actors inside your application. They can sometimes include relationship links as well, these include
      • Composition
      • Encapsulation
      • Aggregation
    • Entities are usually represented by the Class Diagram when first designing the application
  • Controllers
    • The concept of the controller has been around forever. Usually when I ask someone what is a controller they can only reference controllers in an MVC architecture. Controllers in the application tier usually control the flow of data between the presentation and data tiers. In essence they act like police officers directing traffic, each car from a convoy is split into it’s correct lane and in the reverse direction the cars are organized from different lanes into correct convoys respectively. These guys are responsible for constructing entities when they are requested by the presentation tier, and respectively to tear apart entities and send the parts to the proper data source(s) when they are received from the presentation tier.
  • Helpers
    • Helpers are usually methods or operations that perform any task but are refactored. They can include anything from simple string operations to complex array sorting and searching algorithms. They usually are not “strictly” related to the application but rather are generic functionalities that are shared between projects.

Data Tier

“The data tier is composed of a database.”


The data tier can be composed of one database but it does not have to. What if you need to integrate, for example, a google api into your app? What if some info is stored on the hard disk in an XML file for use by another application later on?

The point is that the data tier is composed of any relevant data source where you need to write and/or read information. Period!

In short, using the three tier architecture model will help you logically order your code. It will make your application neater, you will not have to remember what is where and most of all you will get a very clear picture of how your app works.

Leave a comment

Your email address will not be published. Required fields are marked *