Servicios y lógica de negocio en NestJS

Contenido del curso

Fundamentos y Primer CRUD

Base de Datos y Persistencia con TypeORM

Autenticación y Autorización

Tu API Completa

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0025:09

Servicios y lógica de negocio en NestJS

Curso de Backend con NestJS

Clase 8 de 35

Clase 8 / 35

Recursos

Cuando construyes una API con NestJS, llega un punto donde el controller empieza a hacer demasiado: expone endpoints, valida datos y, además, manipula la información. Ahí es donde entran los servicios en NestJS, la capa que centraliza la lógica de negocio y aplica principios de arquitectura limpia como single responsibility y singleton.

Si vienes trabajando solo con controladores, este es el salto que vuelve tu código escalable, reutilizable y fácil de mantener.

¿Por qué separar el controller del servicio en NestJS?

El problema aparece cuando un mismo archivo expone endpoints y, al mismo tiempo, decide cómo guardar, buscar o validar la data. Eso rompe el principio de responsabilidad única de SOLID.

En NestJS, la división se ve así:

El controller expone el endpoint, define el protocolo (GET, POST, DELETE) y valida la entrada con DTOs.
El servicio maneja la lógica de negocio: insertar, actualizar, buscar, eliminar.
El model define la estructura interna de la entidad, distinta del DTO.

¿Qué hace un servicio en NestJS? Es una clase decorada con @Injectable() que contiene la lógica de negocio y se inyecta en los controladores u otros servicios mediante el constructor.

Normalmente vas a tener una paridad: una entidad, un controller, un servicio. Si tu base de datos tiene 20 tablas, probablemente tendrás cerca de 20 servicios, aunque no siempre 20 controllers, porque algunas entidades son internas y no se exponen [05:30].

¿Cómo crear un servicio con el CLI de Nest?

Desde la terminal, el generador de Nest crea el archivo, el test y actualiza el módulo automáticamente:

bash nest generate service users

Esto produce tres acciones:

Crea users.service.ts con el decorador @Injectable().
Crea el archivo de pruebas users.service.spec.ts.
Actualiza app.module.ts para registrar el servicio en providers.

Antes de migrar la lógica, conviene mover la interface del usuario a un archivo user.model.ts y exportarla. Así separas claramente el DTO (validación de entrada) del model (esquema de la data guardada) [07:40].

¿Cómo funciona la inyección de dependencias y el patrón singleton?

Una vez creado el servicio, el controller lo recibe en el constructor:

ts constructor(private usersService: UsersService) {}

Esa línea hace dos cosas. Primero, declara usersService como propiedad privada del controller. Segundo, le indica a NestJS que debe inyectar una instancia de UsersService.

Y aquí viene lo interesante: gracias al decorador @Injectable(), NestJS aplica el patrón singleton. Es decir, no importa cuántos controladores inyecten el mismo servicio, siempre se crea una sola instancia. Si se replicara, tendrías múltiples arrays de usuarios en memoria, cada uno con data distinta. Con singleton, todos apuntan a la misma fuente.

¿Qué es el patrón singleton en NestJS? Es un patrón donde una clase tiene una única instancia compartida en toda la aplicación. NestJS lo aplica por defecto a todo provider decorado con @Injectable().

¿Cómo migrar la lógica del controller al servicio?

La idea es vaciar el controller hasta dejarlo solo con la exposición del endpoint. Cada método del controller llama al servicio y retorna su resultado.

En el ejemplo de la clase, el servicio termina con estos métodos públicos:

findAll() retorna todos los usuarios.
findOne(id) busca un usuario por ID y aplica la regla de negocio que prohíbe acceder al ID 1 con un error 403 [13:20].
create(payload) recibe el CreateUserDTO, autogenera el ID e inserta en memoria.
update(id, changes) recibe el UpdateUserDTO y actualiza solo los campos enviados.
delete(id) elimina el usuario por posición.

Y un método privado clave: getUserById(id). Este se encarga de retornar la posición del usuario en el array y lanza NotFoundException si no existe. Es privado porque solo se usa internamente para reutilizar lógica entre update, delete y findOne.

El resultado es que el controller queda así de limpio:

ts @Get(':id') findOne(@Param('id') id: string) { return this.usersService.findOne(id); }

¿Dónde van las excepciones, en el controller o en el servicio?

Van en el servicio. NotFoundException o el error 403 de autorización forman parte de la lógica de negocio: depende de si el dato existe o cumple ciertas reglas. Manejarlas en el servicio evita duplicar validaciones y mantiene el controller enfocado solo en exponer rutas [16:50].

¿Por qué reutilizar DTOs también en el servicio?

Aunque la validación ya ocurrió en el controller gracias a class-validator, tipar los parámetros del servicio con el mismo DTO mantiene consistencia y aprovecha el contrato de datos. Cuando la información llega al servicio, ya viene con integridad garantizada: el email es válido, el nombre es string, los campos opcionales están marcados con @IsOptional().

¿Cómo resolver el reto del UpdateUserDTO?

La solución del reto anterior consistió en clonar el CreateUserDTO, renombrarlo a UpdateUserDTO y agregar el decorador @IsOptional() a cada campo. Así, los campos siguen siendo string o email válido, pero ya no son obligatorios.

Luego, en el método update del controller, en lugar de tipar el body con la interfaz, se usa UpdateUserDTO. Eso elimina las validaciones manuales dentro del método, porque la capa del DTO se encarga.

Para probarlo: si envías un name numérico, la API responde con un error indicando que debe ser string. Si envías solo name sin email, la actualización funciona porque el email es opcional [03:10].

¿Qué ganas al aplicar este patrón en tus APIs?

La refactorización deja varios beneficios concretos:

Eliminas duplicación de código (la búsqueda por ID se centraliza en un método privado).
Tu controller queda enfocado solo en exponer endpoints.
Puedes inyectar el mismo servicio en varios controladores sin replicar instancias.
Las excepciones viven junto a la lógica que las dispara.
El código se vuelve testeable, porque el servicio se puede probar de forma aislada.

Ahora te dejo el reto de la clase: inyecta el UsersService también en el AppController. Vas a comprobar que NestJS mantiene una sola instancia compartida entre ambos controladores. ¿Lo intentaste? Cuéntame en los comentarios cómo te fue con la inyección desde el segundo controller.

Francisco Antonio Hernandez Sabatino

Hace un año•editado

Controller:

import { Controller, Get, Post, Put, Delete, Param, Body, HttpCode, HttpStatus } from '@nestjs/common';
import { UsersService } from './users.service';
import { CreateUserDto, UpdateUserDto } from './user.dto';
import type { IUser } from './user.model';

@Controller('users')
export class UsersController {
  // Inyectamos nuestro servicio limpio
  constructor(private readonly usersService: UsersService) {}

  @Get('/')
  getAllUsers(): IUser[] {
    return this.usersService.getAllUsers();
  }

  @Get('/:id')
  getUserById(@Param('id') id: string): IUser {
    return this.usersService.findUserById(id);
  }

  @Post('/')
  createUser(@Body() createUserDto: CreateUserDto): IUser {
    return this.usersService.createUser(createUserDto);
  }

  @Put('/:id')
  updateUser(@Param('id') id: string, @Body() updateUserDto: UpdateUserDto): IUser {
    return this.usersService.updateUser(id, updateUserDto);
  }

  @Delete('/:id')
  @HttpCode(HttpStatus.NO_CONTENT) // Para que devuelva 204 en éxito
  deleteUser(@Param('id') id: string): void {
    return this.usersService.deleteUser(id);
  }
}

Service:

import { Injectable, NotFoundException, ConflictException } from '@nestjs/common';
import { IUser } from './user.model';
import { CreateUserDto, UpdateUserDto } from './user.dto';

@Injectable()
export class UsersService {
  private users: IUser[] = [
    {
      id: '1',
      name: 'John Doe',
      email: 'email@email.com',
    },
    {
      id: '2',
      name: 'Jane Does',
      email: 'jane@email.com',
    },
  ];

  getAllUsers(): IUser[] {
    return this.users;
  }

  findUserById(id: string): IUser {
    const user = this.users.find((user) => user.id === id);
    if (!user) {
      throw new NotFoundException(`Usuario con ID '${id}' no encontrado.`);
    }
    return user;
  }

  createUser(createUserDto: CreateUserDto): IUser {
    const emailExists = this.users.some((user) => user.email === createUserDto.email);

    if (emailExists) {
      throw new ConflictException(`El email '${createUserDto.email}' ya está en uso.`);
    }

    const lastId = this.users.length > 0 ? Number(this.users[this.users.length - 1].id) : 0;
    const newId = (lastId + 1).toString();

    const newUser: IUser = {
      id: newId,
      ...createUserDto,
    };

    this.users.push(newUser);

    return newUser;
  }

  updateUser(id: string, updateUserDto: UpdateUserDto): IUser {
    const user = this.findUserById(id);
    const updatedUser = { ...user, ...updateUserDto };

    this.users = this.users.map((u) => (u.id === id ? updatedUser : u));
    return updatedUser;
  }

  deleteUser(id: string): void {
    this.findUserById(id);

    this.users = this.users.filter((user) => user.id !== id);
  }
}

Module:

import { Module } from '@nestjs/common';
import { UsersService } from './users.service';
import { UsersController } from './users.controller';

@Module({
  imports: [UsersModule],
  controllers: [UsersController],
  providers: [UsersService],
})
export class UsersModule {}

App.Module:

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { UsersModule } from './users/users.module';

@Module({
  imports: [UsersModule],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

Comentarios (12)12 comentarios

Platzi Team

Hace un año

Juan Pablo Amador Díaz

Xavier Alberto Castillo varon

Hace 8 meses

Hearly Sebastian Huertas Perez

Hace 3 meses

Juan Diego Mejia Maestre

Hace 6 meses

Jhonatan Celis Rincón

Maria Alejandra Luna Tito

Edward Alexis Uceda Jara

William Javier Del Valle Meza

Hans Uriel Diaz Aguilar

Henry David Fajardo Lagos

José Isaza

Nicolas Molina

Profesor

Fundamentos y Primer CRUD

Crea una API RESTful con NestJS

Instalación del CLI de NestJS y primer proyecto con API

Creación de endpoints dinámicos para consultar usuarios en NestJS

Operaciones CRUD en APIs REST con Postman

Método PUT para actualizar usuarios con ID automático

Manejo de status codes HTTP en NestJS

DTOs y validación automática de datos en APIs con NestJS

Servicios y lógica de negocio en NestJS

Variables de entorno seguras en NestJS

Programación modular en NestJS con UserModule

Base de Datos y Persistencia con TypeORM

Configuración de PostgreSQL con Docker y Docker Compose

Configuración de PostgreSQL con TypeORM en aplicaciones NestJS

Creación de entidades ORM con decoradores en TypeScript

Repository Pattern con TypeORM en NestJS

Relaciones uno a uno entre usuarios y perfiles en PostgreSQL

Actualización de DTOs con mapped types en NestJS para perfil y usuario

Generación automática de módulos CRUD con NestJS y AI

Relación uno a muchos con TypeORM

CRUD de categorías con IA en NestJS

Relaciones many-to-many con TypeORM y validación de arrays

Reutilización de servicios entre módulos en NestJS

Migraciones en TypeORM sin perder datos

Cómo evitar perder datos al migrar columnas

Autenticación y Autorización

Hashing de contraseñas con Bcrypt en NestJS

Excluir campos sensibles con ClassTransformer

Autenticación local con Passport en NestJS

Endpoint de login con Passport en NestJS

Implementación de JSON Web Token para autenticación en NestJS

Rutas protegidas con JWT en NestJS

User ID automático desde JWT en NestJS

Tu API Completa

Autogenera resúmenes e imágenes con OpenAI en NestJS

Documentación automática de APIs con Swagger en NestJS

Preparar tu API NestJS para producción

Desplegar aplicación Node.js a producción con Railway y PostgreSQL

Desarrollo de API REST escalable con NestJS en producción

Servicios y lógica de negocio en NestJS