NestJS

Estructurar la aplicación con módulos que representen capacidades de negocio, no carpetas arbitrarias.

Mantener los controladores centrados en el transporte HTTP mientras los servicios contienen el comportamiento de dominio.

Usar inyección de dependencias para que la orquestación, las pruebas y el reemplazo de colaboradores sean previsibles.

Tratar el framework como una herramienta de límites del sistema, no como una capa decorativa sobre código desordenado.

Exponer APIs capaces de servir sitios públicos, aplicaciones móviles, paneles admin y flujos internos.

Mantener autenticación, permisos, reglas de negocio y efectos secundarios coherentes en todos los puntos de entrada.

Diseñar módulos para que el crecimiento del producto no genere automáticamente un servicio monolítico con dependencias ocultas.

Preparar el backend para notificaciones, auditoría, facturación, medios, soporte y analítica.

Definir límites de módulo con lenguaje de negocio: usuarios, auth, facturación, chat, reclamaciones, wallet o gamificación.

Exponer servicios públicos claros en lugar de permitir que cualquier módulo entre directamente en otro.

Separar facades, readers, orquestadores y servicios de dominio cuando la complejidad lo justifique.

Evitar servicios gigantes que validan entradas, ejecutan queries, disparan eventos y formatean respuestas al mismo tiempo.

Usar DTOs para definir la forma aceptada de las entradas públicas en lugar de confiar en cuerpos de petición sin validar.

Mantener descripciones Swagger, ejemplos, códigos de estado y decoradores de validación consistentes.

Documentar respuestas de error y casos límite para que los consumidores de la API no tengan que adivinar.

Usar herramientas de verificación OpenAPI como Schemathesis para detectar deriva entre documentación e implementación.

Usar guards para aplicar autenticación, roles, propiedad y reglas de acceso sensibles de forma explícita.

Validar todas las entradas públicas y evitar debilitar DTOs solo para que pasen tests o demos.

Mantener errores de negocio estables, legibles y seguros para exponer mediante APIs públicas.

Proteger flujos sensibles como login, refresh tokens, acceso admin, facturación, uploads y cambios de cuenta.

Usar transacciones Prisma en flujos que deben confirmar varios cambios relacionados a la vez.

Mantener claves de idempotencia, referencias de origen y constraints únicos cerca de la regla de negocio que protegen.

Evitar ocultar decisiones importantes de persistencia detrás de helpers genéricos que dificultan la revisión.

Verificar formas de query, campos seleccionados, ordenación, filtros y ramas transaccionales con pruebas dirigidas.

Mantener los WebSocket gateways ligeros y mover el comportamiento de dominio a servicios u orquestadores.

Separar la respuesta inmediata de la API de efectos como notificaciones, emails, analítica y auditoría.

Diseñar nombres de eventos, payloads y reglas de entrega como contratos, no como detalles casuales.

Hacer el realtime suficientemente observable para depurar chat, presencia, soporte y flujos admin.

Escribir tests unitarios para decisiones de servicio, rutas de excepción, guards, DTOs y ramas fallback.

Usar tests de integración y E2E para colaboración real de módulos, comportamiento de base de datos y flujos HTTP públicos.

Ejecutar Schemathesis contra el contrato OpenAPI, k6 para señales de rendimiento y OWASP ZAP sobre superficies expuestas.

Usar Stryker para comprobar que las aserciones detectan regresiones en lugar de solo ejecutar código.

El codebase puede absorber nuevas reglas de producto sin reescribir módulos no relacionados.

Seguridad, validación, transacciones y reglas de acceso siguen firmes incluso cuando fallan los tests.

El repositorio expone scripts claros para typecheck, lint, build, tests, contratos, smoke checks y mutation testing.

Un nuevo desarrollador puede entender los límites de módulo, ejecutar la cadena de calidad y modificar una función sin romper la plataforma.