I think there are 5 layers to an Api Service
graph TD Client --> DTO[DTO Layer] DTO --> Controller[Controller Layer] Controller --> Service[Service Layer] Service --> Repository[Repository Layer] Repository --> ORM[ORM Layer] ORM --> DB[(Database)]
So now the question comes which particular layer is something we should solve first
The Top Down Approach
If you would have asked me 2-3 years back I would have said ask the client what he wants and make the changes from top to down
In this approach
- You see what the client Wants and based on that you solve the problem
- It goes from DTO layer to the Database
- Very easy to start
- Awesome for small projects
- Mostly used in javascript and python
- But very soon I realised this was tough to manage as client
😰 Why it becomes tough to manage
- Your code is driven by external shape, not internal structure.
- You might end up calculating or transforming the same logic in many places.
- There’s no centralised domain model or internal structure — just DTOs shaping everything.
- Any change in client needs may ripple down and require deep refactoring.
- DTOs become bloated with logic, service layers become glue code.
💡🕯️🕯️In recent years I understood database is the truth of a system. So that’s the first thing one should design.
- This approach is tough but I should see it as doing a favour for my future self who will be just adding features without fu#king up the system.
Steps to Write an Api Service
- Understand the requirement of the Client
- Fix the database type
- Design the table (model)
- Write the Orm Layer
- Write the service layer
- Join with the controller and Done