Project , Design And I

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.

N-Tier Architecture: 

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 PLSQL. 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.

Front-End Layer: Front end 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 Front End. This will communicate with API/Backend layer and bring RAW data. Then format it with Model.

Model:

This model is the View Model. It’s best not to design additional set of Data models because API/Backend 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

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.

Project, Mistakes and I

I was assigned as a team leader for an office project . There were two developers under my command.
To make the project successful I took various steps . Some of those steps didn't prove to be effective.
I'm going to point out some key mistakes of mine.

•  Held the wheel most of the time 

I thought it would be wise to navigate the ship myself while teaching my team how to do likewise. Maybe it would have worked in some cases. But in my case it didn't work out as well as I had expected. On the contrary it backfired. My Crew never got the practical knowledge . When I let them take the wheel, they were at a loss in the middle of a sea. They were over whelmed. Even though I did follow a pattern in the project. Even though they did write 80% of the code. They got lost as soon as I left them to code alone. Well the best way to learn is by making mistakes. Everything I learnt was from my mistakes. I took that away from them and hence I took away their learning mechanism.

• Easy way out

Funny you may think. It does sound stupid. If I don't share my knowledge with my team, what's the point of being the leader? Here's the catch. I learned that solution from facing a problem and thinking about it. I had learned more than the specific problem when I was researching. But when I gave away the specific solution. I actually stopped their thinking process. They might have come up with a better idea. But since the problem was solved, their brains lost interest about thinking about better solution as any human being would.They didn't learn how to google for the problem. As a result when new problems came up. They were looking for my assistance instead of Google's.

• LEGO Design
  
  

One of my most favorite ways to develop a software is to break it down to small modules as such as LEGO blocks. So that I can just plug it in into any future project. I'm a lazy programmer. I don't want to write the same code twice.

When I assigned task for my team members I only gave them small objectives with small outcomes. I asked them to build LEGO bricks for me. They did. But they couldn't see the bigger picture I had in my mind since I didn't exactly share what was I going to do once I have the bricks ready. Although my plan was to make them use their own bricks and build a castle. They were at a loss when I asked them to build the castle . They went back to thinking about how to build bricks. Which they had already done with out knowing. At some point they did realized that the work was done long before. But Since I never explained the actual purpose of the bricks , They were unable to join them all together. Just because I knew what the small bricks can be used for , that doesn't mean my team will actually be able to think that far.



Best way to learn is to learn from mistakes. Even a team leader makes mistakes. We are but human.