N-Tier Architecture

Design of a project structure will start mattering when you are working on a huge project with multiple peoples. It’s very easy to get lost on where what is written. This is why Design Patterns came to be. One of the most popular and most flexible design pattern of a project is n-tier architecture. I’ll be talking about this design pattern on this post.

I’ll call the Whole project as solution. No, I’m not talking about C# projects only. Declaring this because otherwise this term project will confuse readers in multiple places.

It basically divides the whole solution into multiple tiers. Each tier will work with one type of concern. N stands for your tier numbers. For instance, your project can be 3-Tier,4-Tier etc. It can also be 1-Tier as well. For small solution it’s very common to follow a 1-tier Architecture since there are very little concerns to think about. Another thing to be clarified, one solution Should have only one executable. If it has multiple executables it should be divided into multiple layers instead of multiple tiers. We will talk about multi layered project another time but for now just know that each layer is one standalone executable.

How many tiers should one Solution have?

Well that’s a very good question but there is no definite answer. It’s all about personal preference. The more experience you have the more tiers you can define before starting the solution. From my experience each solution usually creates multiple tiers that I never needed before. But I could always suggest a few templates.

But First let’s talk a bit about layers, Always breakdown executables into layers. The current pattern that the world follows for designing any database related application is that it always has an API layer. A Database layers. And obviously multiple Front-End Layers. Bear with me if you got lost already. Well Front-End Layer is basically the UI Solution that Only Requests Data from the server and shows it to the clients. Almost Zero Logic related tasks are performed here. A Standard Solution should follow this rule. But you know… It’s hard to follow the rule everywhere. The API Layer, is where all the calculations happen. Well you could burden the database with complex queries to do most of the calculation for you. But As far as I know it’s best to bring data from the database layer and do the calculations on this layer. And ofc Database Layer, which most of us usually ignore. But Did you know you can Code on Database as well. Which is called PL-SQL. A well-designed project should implement PL-SQL on database and define triggers and some more things on the Database Side. Now each layer is divided into multiple tiers.

API Layer Breakdown:

Let’s start with API layer breakdown. Well there’s no definite number that must be followed. Your solution might need less tiers or more. But most commonly there are 3 tiers.

Application:

This tier is the entry point of the layer. All the API configurations such as routing, white-listing are done here.

Business Logic:

This tier is basically the Core of the project. The application layer only accepts request and returns some message(Data). The business logic tier is the part where you define what should be returned and in what format etc.

Repository:

This tier is where you communicate with database. Business logic layer communicates with Repository to get data from database. Here’s the part where you write down Queries of Database. NO, I mean no Queries should be written outside of this part.

Now There are some Tiers that I Strongly recommend making. But first I forgot to mention about Model/Converter Projects. These are easily Mistaken as Tiers but I don’t want to call them as Tiers. Because their sole task is to make other tiers communicate with each other.

Special Type of projects:

Data Model:

This model represents the database. This model will be used to communicate with database.

View Model:

This is usually made optional. But I strongly recommend making one View model project. In most cases the view model and data model are same. But that’s not always true. You might want to show data from multiple tables on a single view. What’s a View you ask? View is basically what the clients See. It can be an HTML Page.

Converter:

If you make a view model project you will need another project that converts view models into data models and vice versa. Initially you will feel like this is just a hassle but trust me this will make the Solution much more readable.

Why Do I recommend the view model and converter along with Data model On API Layer?

Because Usually front-end developers are a different team. They need not to be burdened with database’s design. It’s easier for them to communicate with the API layer with a View model. It’s not just easier it’s also faster. Because then front-end developers won’t have to create a Conversion project with a different View model. Because that’s what they would end up doing. So, it’s best practice to design the logical parts on the API layer not on Front-End Application layer. One way or another these 2 Projects are added to the solution. Better do it on the API layer.

More Breakdown: You can breakdown the layer into more tiers. For example, you could even make Business logic into 2 different project that suits your need.

Database Layer: I’m no database architect so I can hardly tell anyone what to do. But as much as my knowledge serves It has a few configuration stuffs. PL SQL part and Triggers. These should be taken care of.

Application Layer: Application layer could get complex depending on Technology. And platform. But there are some basics that can be commonly described.

Controller:

Controller is what handles the request. This is the head of Application. This will communicate with API layer and bring RAW data. Then format it with Models.

Model:

This model is the View Model. It’s best not to design additional set of Data models because API layer wasn’t optimized for View Model. But in most cases, you won’t get a perfect view model. So, you will probably need another data model project with converter.

View:

This project will only contain views that the client sees. No logic should be written here other than those that construct the view with Models. This is basically done with GUI tools like HTML.

Now know that this is not some absolute rule. Rather a starting point. Each project is unique. Most of the time you will need to configure these layers and tiers as your project suits. Instead of memorizing the pattern feel the pattern and understand it.