When a project starts, life is simple. You know how things are wired, and adding a new feature feels effortless. But as the system grows, that mental model collapses. Without design patterns, codebases slip into chaos.

Even if you are following MVC pattern, if you don't have proper design patterns in place, it's easy to create a mess.

The Buckets of Backend Code

Most backend logic falls into these buckets:

• Controller: Handles requests
• Service: Business logic
• Repository: Database access
• Core : Shared utilities (auth, config, logging)
• Infrastructure → External systems (DB, cache, metrics)

There is two thing we can do about it,

1. Either don't care about design principle & just watch your system rot.
2. Or we can follow a proper design patterns and organize code like a really engineer.

Design Pattern Buckets

There are 3 fundamental buckets of designing principle.

1. Creational Pattern : How entities are created?
2. Structural Pattern: How entities are organized?
3. Behavioral Pattern: How entities behave with each other?

We’ll focus on one of the most useful creational patterns: the Factory Pattern.

The Factory Pattern

A Factory centralizes object creation so that services, repositories, and infrastructure are instantiated once and reused everywhere.

• The Controller, Service, Repository, Core, and Infrastructure are like different stations on the factory floor.
• The Factory Pattern is the system that wires all these stations together. It decides:
• Which service needs which repository
• How infrastructure (DB, error handler) is injected into services
• How controllers always get the same service instance, not a fresh one each time

1. Routes → Controller (The Intake Dock)
2. Requests enter through routes and land in controllers.
3. Controllers do light work: validation, checking if the request is shaped correctly.
4. Services (The Assembly Line)
5. Business logic lives here.
6. But instead of building dependencies (like repositories or DB clients) by hand, services are provided by the Factory.
7. Repository (The Warehouse)
8. Handles database operations.
9. Services don’t know how data is stored; they just request it from repositories.
10. Core (The Toolkit)
11. Shared infrastructure like JWT tokens, configs, loggers, or error handling.
12. Think of this as the tools the factory workers rely on.
13. Infrastructure (The Heavy Machines)
14. Database connections, external APIs, and error handlers.
15. These are powerful but costly to manage, so the Factory ensures they’re only created once and reused everywhere.
16. Response Builder (The Shipping Department)
17. Standardizes every output into neat envelopes: SUCCESS, ERROR, REQUEST.
18. No matter what happens inside, the client gets a predictable package.

class Factory {
  private static instance: Factory;
  private core: any;
  private infra: any;
  private repos: any;
  private services: any;


  private constructor() {}


  static getInstance() {
    if (!ServiceFactory.instance) {
      Factory.instance = new Factory();
    }
    return Factory.instance;
  }


  getCore() { /* return ...core */ }
  getInfrastructure() { /* return ...infra */ }
  getUtilities() { /* return ...utilities */ }
  getRepositories() { /* return ...repos, */ }
  getServices() { /* return ....services */ }
}

usage:

const aService = factory.getInstance().getAService();

Anywhere you need a service, you don’t build it yourself.

the Factory hands it to you.

Think of it like this:

If you need a bike, you don’t start by welding the frame, bolting the wheels, and tuning the gears. You just walk into the shop and get a bike. The factory already did the complex, messy work of assembling it.