Diseño de Clean Architecture en NodeJS

NodeJS es una de las tecnologías centrales que usamos en SolidGEAR para dar vida a nuestras aplicaciones. Pero como en todas las tecnologías, la parte crítica no es la propia tecnología sino como la usamos para conseguir lo que necesitamos. Por lo tanto, en este post vamos a recopilar toda la experiencia que hemos ganado trabajando con NodeJS para definir una buena arquitectura, que sabemos que funciona y basada sobre todo en conceptos como ‘Clean Architecture‘ y ‘Arquitectura Hexagonal‘ para que podáis seguirla y diseñar vuestro backend de manera que se pueda adaptar a la mayoría de proyectos y escalar de manera apropiada

Blocks Ready - Clean Architecture

No se trata de una guía definitiva para diseñar la aplicación perfecta. Posiblemente se puedan aplicar muchas mejoras, sobre todo en función de las necesidades de cada proyecto. Pero puedes aprovecharte de nuestro trabajo previo y varios años de testear esta arquitectura para ahorrarte problemas y dolores de cabeza cuando te encuentres en medio de un proyecto que ha evolucionado de manera imprevista.

Problemas ocultos en algunas arquitecturas NodeJS

Empecemos diseñando una arquitectura NodeJS por nuestra cuenta. Muchos de los conceptos pueden ser extrapolados a otras tecnologías, pero centrémonos en esta. Escogeremos Express como framework para el API (basado en REST) y MongoDB (con Mongoose) para la base de datos, ya que el stack MEAN se ha popularizado bastante en los últimos años. Sin embargo, muchos de los conceptos utilizados en esta sección serán transparentes al stack tecnológico utilizado

Podemos ver un ejemplo de servidor básico NodeJS en este link, el cual básicamente tiene un recurso que nos permite crear un ‘usuario’:

https://github.com/siro47/CornerCleanArchitectureNode/tree/v1

Este servidor tiene algunos buenos principio detrás. Tiene capas separadas para gestionar las peticiones del API y las consultas de base de datos. Ficheros separados para módulos de los recursos REST, y también para módulos de bd (aunque para este ejemplo solo se ha añadido un módulo de gestión de usuarios). Parece que podría escalar sin ningún problema según aumente la cantidad y complejidad de los recursos, pero esto no es así del todo.

Hidden hedgehog

Supongamos que hay que añadir un nuevo recurso en nuestro server para crear un grupo. Un grupo está diseñado para contener usuarios. Pero nuestra lógica de negocio determina que un grupo debe crear un usuario por defecto que se encargará de gestionar dicho grupo. Los primeros pasos son sencillos de implementar, tal y como podemos ver aquí:

https://github.com/siro47/CornerCleanArchitectureNode/tree/v2

¿Pero como vamos a poder reutilizar nuestro código previo para la creación del usuario?

Importar el método de la capa ‘routes’ causa problemas, ya que vamos a necesitar pasar objetos de express (‘req’, ‘res’, …) de un sitio a otro de nuestra aplicación. Importar el método de la capa ‘db’ no es del todo preciso, ya que estamos perdiendo funcionalidad estratégicamente añadida en la capa de ‘routes’ (crear la variable completeName del usuario).

Thinking

Además, vamos a considerar que queremos añadir test unitarios (porque efectivamente, queremos test unitarios en nuestro código) a nuestra funcionalidad actual. Los test de la capa ‘routes’, ¿no van a estar demasiado ligados a express? Si cambiásemos a, por ejemplo, un API en GraphQL, ¿tendríamos que reescribirlos de nuevo?

¿Cómo resolveríais estos problemas? ¿Dividiendo los métodos actuales? ¿Creando una capa nueva? ¿Muchas capas nuevas, quizás?

No reinventemos la rueda. Clean Architecture + Arquitectura Hexagonal

No vamos a descubrir una solución innovadora. Simplemente hemos evaluado los mejores modelos de arquitectura disponibles actualmente y los hemos adaptado a nuestras necesidades.

Comenzamos analizando uno de los patrones de arquitectura más conocidos, propuesto por Uncle Bob hace unos años y llamado Clean Architecture. Se basa en la idea de hacer el modelo independiente del framework, librerías, bds… (suena lógico, no?), creando una capa intermedia llamada ‘adaptadores de interfaz‘. Hace incapié también en la necesidad de que el código sea fácilmente testable, y como este tipo de arquitectura nos facilita la creación de test unitarios que no están ligados a ningún elemento tecnológico externo.

Adicionalmente, analizamos otro modelo de arquitectura bastante utilizado, la Arquitectura Hexagonal, propuesta por Alistair Cockburn en 2005. Hablan de diferentes formas geométricas, pero sus conceptos son muy similares. Encapsular la funcionalidad de tu aplicación para ser usada por cualquier elemento externo a través de un sistema de puertos y adaptadores

Matching pieces. Clean Architecture + Hexagonal

Ergo siguiendo estos principios, separamos la lógica de negocio de nuestro framework de API, creando una nueva capa ‘domain’:

https://github.com/siro47/CornerCleanArchitectureNode/tree/v3

Consiguiendo de esta manera:

  1. Nuestro código del dominio es reusable e independiente del framework del API
  2. El código es fácil de testear y los tests pueden perdurar a través de diferentes frameworks y cambios de librerías

Como podemos ver en la versión final del ejemplo, la funcionalidad central permanece invariable a pesar de que hemos añadido una API basada en GraphQL que utiliza los mismos métodos del dominio. No solo eso, sino que hemos creado test unitarios que aseguran el correcto funcionamiento de nuestro lógica de negocio de manera autónoma, usemos el framework de API que usemos.

Mejoras adicionales

Tools

Como hemos dicho previamente, esta es simplemente una arquitectura base sobre la que vosotros deberíais adaptar las necesidades de vuestro proyecto. Además, para evitar que este post se volviera demasiado extenso, no hemos entrado en detalle de ninguna de las siguientes mejoras, pero es deber del lector avanzado tener en cuenta también los siguientes puntos. (Y podéis preguntarnos por más información de cada uno en la sección de comentarios de debajo, si queréis)

  • Mejorar la definición de los adaptadores de API: Nuestro adaptador de API REST separa nuestra lógica de negocio de los recursos, peticiones, respuestas y demás cosas de REST. Pero una capa más completa debería incluir también mapeado de códigos http, mensages internacionalizados y todo lo necesario para sacar el máximo partido de nuestro protocolo de API.
  • Añadir adaptador a la capa de bd: De la misma manera que hemos dividido nuestra tecnología de API de nuestro código, deberíamos hacer lo mismo con la capa de base de datos, para hacer que nuestra aplicación sea totalmente independiente de la tecnología de bd que estemos usando. De manera análoga, deberíamos añadir un adaptar para cada uno de los frameworks externos que queramos aislar de nuestro código de dominio.
  • Definir entidades de dominio: Algunos modelos de Clean Architecture hablan sobre definir entidades núcleo en nuestro lógica de negocio para abstraerlas en una capa más interna. Eso depende de la aplicación, pero es algo que deberías tener en cuenta sobre todo si tienes entidades bien definidas que se usan en toda la lógica de tu aplicación.

¿Listo para enfrentarte al desafío de tener un servidor NodeJS escalable y listo para adaptarse a cada situación?

¿Hay algo más que piensas que es imprescindible en una buena arquitectura NodeJS?

 

Y si quieres saber como hacer tu primera API REST con Node JS + Express:

Artículos relacionados

Lo mejor y peor de Mocha y de los unit tests en JavaScript

 

7 comentarios en «Diseño de Clean Architecture en NodeJS»

  1. Hola Siro:

    En primer lugar es un excelente articulo, el codigo queda bastante limpio y desacoplado 😉 una consulta prodrias dejar en el git el archivo package.json para levantar rapidamente el proyecto? el que esta se encuentra vacio.

    Muchas Gracias por tu aporte

    Responder
  2. Buen artículo Siro.

    Este año, me he dedicado a aprender el stack JavaScript y vaya que me gusta. Lástima que por acá (Venezuela) el «todopoderoso» es Java, en menor medida .NET y PHP.
    Pero una duda, ¿Dónde puedo conseguir información de los patrones de diseño que se puedan emplear y ayuden al desarrollo en Node.JS?
    Muchas gracias.
    ¡Saludos!

    Responder
    • Buenas Gustavo,

      la verdad que si me decidí a plasmar todo esto aquí es porque he visto muy poca información sobre patrones de diseño en Node. Toda la información que ves aquí es en base a nuestra experiencia y experiencia compartida con otros colegas de profesión.
      Te puedo decir que en nuestro canal de youtube vamos a ir subiendo varios videos de desarrollo en Node que seguramente te resulten interesantes, y en cada uno recopilaremos también todos los links que vayamos encontrando útiles.

      Responder
  3. Muy buen artículo! Una duda, por lo que entiendo la dependencia debería ir de la capa de base de datos (detalle se infraestructura) al dominio (abstracciones del negocio), y no al revés, como pasa en v3. ¿Se te ocurre cómo invertir esa dependencia?

    Responder
  4. Buena explicación, te felicito!
    Una pregunta, mencionas un ejemplo de test unitario en el proyecto explicado, pero no veo esa implementación. Si pudieras, podrías enviarme un proyecto que tenga implementado los test unitarios?. Gracias.

    Responder

Deja un comentario

¿Necesitas una estimación?

Calcula ahora

Centro de preferencias de privacidad

Cookies propias

__unam, gdpr 1P_JAR, DV, NID, _icl_current_language

Cookies de analítica

Estas cookies nos ayudan a comprender cómo los usuarios interactúan con nuestra página web.

_ga, _gat_UA-42883984-1, _gid, _hjIncludedInSample,

Cookies de suscripción

Estas cookies se utilizan para ejecutar funciones de la Web, como no mostrar el banner publicitario y / o recordar la configuración del usuario dentro de la sesión.

tl_3832_3832_2 tl_5886_5886_12 tve_leads_unique

Otra