heylagostechie-vII7qKAk-9A-unsplash

Arquitectura Hexagonal

Sería muy complicado hablar en un solo post sobre está arquitectura, que de todas las existentes en un software es la que más nos apasiona.

Debido a tantos años creciendo junto con los software de nuestros clientes, fuimos acumulando mucha experiencia, y la misma nos indicaba que cualquier software con un crecimiento constante en cuanto a funcionalidades y características inevitablemente iba a llegara a está arquitectura.

Ahora bien, esto te ayuda en algo, sea cual sea la arquitectura que vayas a usar para tu próximo piensala como un microservicio más de tu futura arquitectura hexagonal, en el momento en el que empiezas a pensar así el abanico de posibilidades es inmenso.

Cuando construimos una aplicación tenemos en mente dos cosas importantes:

  1. El cliente necesita cuanto antes salir a producción, o sea que tenemos que priorizar un MVP.
  2. Aunque sea lo más rápido posible la arquitectura DEBE ser «escalable», aclaro que el concepto de esta palabra es muy grande y abierto, y así debe ser, tu estructura tiene que estar preparada para el alcance del proyecto.

Con esas dos premisas planificamos un software, un software guiado por un roadmap con unos objetivos y sprints, donde prima en una primera fase la definición correcta de la arquitectura, evidentemente el software es una «entidad viva» ni de lejos se podrá aceptar, pero ahí es donde entra un pequeño truco que te acercará a la arquitectura hexagonal y es muy simple … piensa en las partes de tu software, como «funciones» en programación básica, algo que es un ente separado, dentro de un ente más grande, pero capaz de ser re-utilizado.

Voy a poner un ejemplo, si tienes que realizar un software, es muy posible que envíes e-mails, pues lo planteamos así:

  1. Siempre, absolutamente siempre plantea tener una API, incluso en el software más pequeño te lo recomendaría, el lenguaje de programación que uses es una herramienta, con lo cual tienes que usar la herramienta perfecta para el trabajo que vas a realizar.
  2. Desvincula el FRONT de la API, si es posible y encaja en el presupuesto del cliente te recomiendo el uso de Angular o React, pero si tienes que hacer un PHP + jQuery, aún así repito no lo unas a tu API, mantén los sistemas separados.
  3. La elección de base de datos, aquí un dato importante, tu API será por ahora tu lector principal de base de datos, con lo cual, escoge una base de datos y lenguaje ( framework ) que estén correctamente alineados.
  4. El envío de e-mails, desaconsejamos profundamente el uso del email local de un plesk o similar, eso es una idea terrible en cualquier tamaño de software, usen servicios de e-mails como Amazon SES o similar ( haremos un post sobre esto seguro ). En cualquier caso, como comentaba, ya sienta las bases para que esté envío de e-mails sea escalable:
    1. Usa un sistema de cola … no entraré en el tema de cual usar o si usar un sistema de PUB / SUB … no, si tu aplicación es pequeña, no te compliques usa la base de datos como sistema de cola, muchos dirán que esto es impensable ERROR … dejad que la aplicación evolucione e id evolucionando la tecnología de acuerdo a ello, de que sirve tener un ferrari si lo llevas a 20 por hora.
    2. Más importante de lo que uses como sistema de cola es que sea re-utilizable y sobre todo que sea modificable, que sepas que en cualquier momento puedes cambiar de proveedor / servicio de cola con la mínima cantidad de cambios.
    3. Una vez que tengas los pasos anteriores … ya tienes la capacidad de conectar CUALQUIER sistema a tu sistema un poco más acercado a la arquitectura deseada … ahora puedes crear servicios, por ejemplo puedes levantar un node con PM2 y ponerlo detrás de un proxy NGINX a la cual en el futuro le puedes ir añadiendo más servidores … ¿no es genial? tres simples pasos y tenemos una arquitectura que nos permitirá conectar lo que queramos.
  5. Tienes que tener un sistema de logs … lo agradecerás infinitamente yo recomendaría desde el minuto uno un sistema de monitoreo externo de logs, el cliente tiene que entender que esto es cómo poner cámaras en un local físico, pero muchas veces los clientes no quieren gastar al principio … así que nos tocará buscar otras maneras de guardarlos … eso sí siempre guarda los logs en un formato que te permita escalar.
  6. Bajo ningún concepto tu aplicación debe crear de manera permanente ficheros en el servidor, SIEMPRE, que necesites ficheros usa o bien servicios como Amazon S3 o similares. Como mismo hay algunas cosas que creo que deben ir evolucionando con el proyecto, está creo que es esencial se haga desde una primera etapa y que uses el mismo sistema que hemos descrito para el envío de e-mails.

Si se fijan algunos pasos que no son difíciles de aplicar, tan solo nos lleva cambiar un poco la forma de hacer las cosas, pero es un buen principio … lamentablemente es solo eso un principio, la arquitectura hexagonal es muy amplia y con el cada vez más creciente concepto de server less se hará más necesaria de utilizar.