Implementando una arquitectura limpia con Nest.JS

Este artículo es para entusiastas que se esfuerzan por escribir código limpio, escalable y, lo que es más importante, refactorizable. Dará una idea de cómo Nest.JS puede ayudarnos a escribir código limpio y qué arquitectura subyacente utiliza.

Implementar una arquitectura limpia con Nest.JS requerirá que primero comprendamos qué es este marco y cómo funciona.

Nest o Nest.JS es un marco para crear aplicaciones Node.js eficientes y escalables (del lado del servidor) creadas con TypeScript. Utiliza Express o Fastify y permite un nivel de abstracción que permite a los desarrolladores utilizar una gran cantidad de módulos (de terceros) dentro de su código.

Profundicemos en lo que es esta arquitectura limpia. 

Bueno, es posible que todos hayan usado o al menos oído hablar de la arquitectura MVC. MVC significa Modelo, Vista, Controlador. La idea detrás de esto es separar la estructura de nuestro proyecto en 3 secciones diferentes.

1. Modelo: Contendrá el archivo Objeto que se asigna con Relación/Documentos en la base de datos.

2. Controlador: Es el controlador de solicitudes y es responsable de la implementación de la lógica comercial y toda la manipulación de datos.

3. Ver: Esta parte contendrá archivos relacionados con la visualización de los datos, ya sean archivos HTML o algunos archivos del motor de plantillas.

Para crear un modelo, necesitamos algún tipo de herramienta/módulo/biblioteca ORM/ODM para construirlo. Por ejemplo, si usa directamente el módulo, digamos 'secuenciar', y luego use el mismo para implementar el inicio de sesión en su controlador y hacer que su lógica comercial principal dependa de la 'secuencia'. Ahora, en el futuro, digamos que después de 10 años, hay una herramienta mejor en el mercado que desea usar, pero tan pronto como reemplace a Sequelize con ella, tendrá que cambiar muchas líneas de código para evitar que rotura. Además, deberá probar todas las funciones una vez más para verificar si se implementó correctamente o no, lo que también puede desperdiciar tiempo y recursos valiosos. Para superar este desafío, podemos usar el último principio de SOLID, que es el Principio de Inversión de Dependencia, y una técnica llamada inyección de dependencia para evitar ese lío.

¿Sigo confundido? Déjame explicarte en detalle.

Entonces, lo que dice el principio de inversión de dependencia en palabras simples es que usted crea su lógica comercial central y luego crea dependencia a su alrededor. En otras palabras, libere su lógica central y sus reglas comerciales de cualquier tipo de dependencia y modifique las capas externas de tal manera que dependan de su lógica central en lugar de que su lógica dependa de esto. Eso es la arquitectura limpia. Elimina la dependencia de la lógica empresarial central y construye el sistema a su alrededor de tal manera que parecen depender de él en lugar de depender de ellos.

Tratemos de entender esto con el siguiente diagrama.

Fuente: Cono de arquitectura limpia 

Puedes ver que hemos dividido nuestra arquitectura en 4 capas:

1. Entidades: En esencia, las entidades son los modelos (reglas empresariales) que definen las reglas empresariales y dicen de qué se trata la aplicación. Esta capa apenas cambiará con el tiempo y suele ser abstracta y no accesible directamente. Por ejemplo, cada aplicación tiene un 'usuario'. Lo que todos los campos debe almacenar el usuario, sus tipos y relaciones con otras entidades conformarán una Entidad.

2. Casos de uso: Nos dice cómo podemos implementar las reglas de la empresa. Tomemos de nuevo el ejemplo del usuario. Ahora que sabemos qué datos operar, el caso de uso nos dice cómo operar con estos datos, por ejemplo, el usuario tendrá una contraseña que debe cifrarse, el usuario debe crearse y la contraseña se puede cambiar en cualquier momento. momento dado, etc.

3. Controladores/Puertas de enlace: Estos son canales que nos ayudan a implementar los casos de uso utilizando herramientas y bibliotecas externas mediante inyección de dependencia.

4. Herramientas externas: Todas las herramientas y bibliotecas que usamos para construir nuestra lógica estarán bajo esta capa, por ejemplo. ORM, Emailer, Cifrado, etc.

Las herramientas que usemos dependerán de cómo las canalicemos a los casos de uso y, a su vez, los casos de uso dependerán de las entidades que constituyen el núcleo de nuestro negocio. De esta manera hemos invertido la dependencia de afuera hacia adentro. Eso es lo que implica el principio de inversión de dependencia de SOLID.

Bien, a estas alturas ya entendiste la esencia de Nest.JS y entendiste cómo funciona la arquitectura limpia. Ahora surge la pregunta, ¿cómo se relacionan estos dos?  

Tratemos de entender cuáles son los 3 componentes básicos de Nest.JS y qué hace cada uno de ellos.

1. Módulos: Nest.JS está estructurado de tal manera que podemos tratar cada función como un módulo. Por ejemplo, cualquier cosa que esté vinculada con el Usuario, como modelos, controladores, DTO, interfaces, etc., puede separarse como un módulo. Un módulo tiene un controlador y un montón de proveedores que son funcionalidades inyectables como servicios, orm, correo electrónico, etc.

2. Controladores: Los controladores en Nest.JS son interfaces entre la red y su lógica. Se utilizan para manejar solicitudes y devolver respuestas al lado del cliente de la aplicación (por ejemplo, llamada a la API).

3. Proveedores (Servicios): Los proveedores son servicios/funcionalidades inyectables que podemos inyectar en controladores y otros proveedores para brindar flexibilidad y funcionalidad adicional. Abstraen cualquier forma de complejidad y lógica.

Para resumir,

• Disponemos de controladores que actúan como interfaces (3ª capa de arquitectura limpia)
• Tenemos proveedores que se pueden inyectar para proporcionar funcionalidad (4ª capa de arquitectura limpia: base de datos, dispositivos, etc.)
• También podemos crear servicios y repositorios para definir nuestro caso de uso (2da Capa)
• Podemos definir nuestras entidades utilizando proveedores de base de datos (1ra capa)

Conclusión:

Nest.JS es un marco poderoso de Node.JS y el texto mecanografiado más conocido disponible en la actualidad. Ahora que conoce los detalles de este marco, debe preguntarse si podemos usarlo para construir una estructura de proyecto con una arquitectura limpia. ¡Bueno, la respuesta es sí! Absolutamente. ¿Cómo? Lo explicaré en la siguiente serie de este artículo. 

Hasta entonces, ¡estén atentos!

Sobre el Autor:

Junaid Bhat trabaja actualmente como Tech Lead en Mantra Labs. Es un entusiasta de la tecnología que se esfuerza por convertirse en un mejor ingeniero todos los días siguiendo los estándares de la industria y alineándose hacia un enfoque más estructurado para la resolución de problemas. 

Lea nuestro último blog: Marco Golang-Beego y sus aplicaciones

Conocimiento que vale la pena entregar en su bandeja de entrada