Si tuvieras que empezar el proyecto que hoy en día estás trabajando desde cero, lo harías con un enfoque de microservicios?
En los últimos años, la popularidad de microservicios ha ido aumentando, sobre todo por ser impulsado por tecnologías como Serverless, K8’s, Docker y servicios de CI/CD.
Pero eso no quiere decir que proyectos con otras arquitecturas sean peores, yo eh trabajado con plataformas increíbles hechas con arquitectura monolita, como Gitlab, Odoo, Django, Moodle, WordPress, etc.
En esta publicación, no pretendo decir que los microservicios es la mejor o peor arquitectura, porque lo cierto es, depende del proyecto, los recursos, modelo de negocio, etc.
Hablar de microservicios es todo un mundo, existe mucha documentación por ahí, como por ejemplo un muy buen libro que estoy leyendo es: Microservices Patterns de Chris Richardson.
Hay mucho más recursos en internet, con lo que uno puede llegarse a abrumar, eso me pasó, y cuando eso pasa, no hay mejor forma de seguir adelante, que aplicar lo que se va aprendiendo.
Esta es la primera de una serie de publicaciones en las que les estaré compartiendo un proyecto con la arquitectura de microservicios.
Pero antes de ir de lleno con microservicios, debemos conocer qué es la arquitectura hexagonal, porqué?, ya verás, sigue leyendo, espérate un tantito.
“La arquitectura hexagonal, también conocida como la arquitectura de puertos y adaptadores, fue propuesta por Alistair Cockburn, un reconocido experto en metodologías ágiles y autor de varios libros sobre desarrollo de software. Cockburn introdujo este concepto en su artículo «Ports and Adapters» («Puertos y Adaptadores») publicado en 2005.”
Lo que me agrada de la arquitectura hexagonal, es que plantea desde el primer momento de la concepción de la idea de desarrollar una aplicación, el separar la lógica de negocio de las herramientas con las que se interactuará, como:
- las interfaces de usuarios
- bases de datos
- integraciones con terceros
y porqué es tan buena esta separación?
hay muchas ventajas, las que destaco son:
- El poder probar cada elemento en capas separadas: dado que las dependencias van de adentro hacia afuera, en el núcleo de la aplicación, es donde está presente la lógica de negocio, se puede probar sin preocuparnos de tener que levantar alguna herramienta de frontend, o incluso del framework que estemos usando en backend. En esta zona está el lenguaje puro, sin dependencias de librerías de terceros.
- Facilidad para implementar features: al tener cada elemento identificado separado en capas, es más fácil poder agregar o modificar código.
- otra ventaja que va de la mano con el punto anterior, es el poder detectar rápidamente dónde pueden estar produciéndose algún bug, el sentido de las dependencias y las capas de esta arquitectura, permiten gestionar elementos que tienen una única responsabilidad.
- existen otras ventajas más, que se pueden englobar en el uso de buenas prácticas a la hora de programar. En este punto voy a desplayarme. No todos los proyectos necesitan ser implementados con esta arquitectura, incluso, no siempre va ser necesario tener implementado las tres capas que se suele mostrar. Existen proyectos que escalan a tal punto que necesitan de más capas. En ese sentido esta arquitectura nos da esa libertad, pero es muy estricto en la implementación de las unidades mínimas, que puede llegar a ser, en cierto punto tedioso y redundante si no se tiene manejo del lenguaje, las herramientas y sobre todo de las operaciones en el negocio que se busca automatizar. Por ello, antes de pensar en implementar una aplicación con esta arquitectura, es recomendable tener definido a qué base de datos nos vamos a conectar, con qué software de terceros vamos a comunicarnos, qué operaciones del negocio se van a cubrir con nuestra aplicación. Cada uno de estos puntos a su vez se desglosan en otras tareas específicas que determinará el alcance del proyecto. Esto es necesario saberlo incluso antes de escribir una línea de código, porque nos facilitará poder escalar el proyecto y conocer las dependencias que tendremos. El tener claro la lógica de negocio, que es el núcleo de nuestra aplicación, y en la que menos cambios habrá, nos ayudará a desarrollar casos de uso, estos a su vez nos permite definir los objetos con los cuales se interactuará en la base de datos, para mostrar reportes y devolver la información que se requiera ya sea a una aplicación web, mobile o comunicarnos con una api de tercero y poder procesar las respuestas.
Llegado a este punto, veo necesario hacer la pregunta,
¿La arquitectura hexagonal es viable aplicar con microservicios?
Cuando hablamos de microservicios, nos solemos referir a herramientas tecnológicas, ya sea el mejoramiento del performance, la comunicación con otros servicios, el escalamiento, despliegue. Pero no perdamos el foco, como su nombre lo dice: microservicios, no son más que servicios que tienen responsabilidades limitadas y forman parte de un producto tecnológico que en esencia busca resolver algún problema o automatizar procesos manuales del negocio.
El tema tecnológico forma parte importante de lo que es microservicios, y a este también debemos sumarle las buenas prácticas, que es lo fundamental, y sobre todo cuando desarrollamos microservicios.
Es por ello que, como las buenas prácticas son importantes y la arquitectura hexagonal nos obliga a seguirlas en la implementación de las mínimas unidades, porqué no usarla en los microservicios?, es más, al ser aplicaciones reducidas, se hace más llevadero.
Y cómo podemos aplicar las buenas prácticas en los microservicios?
te lo respondo en una sola palabra: SOLID.
El tener el conocimiento necesario del lenguaje con el que vamos a trabajar es uno de los conceptos fundamentales si queremos seguir las buenas prácticas, y el conocimiento necesario se logra llegando a implementar los principios de SOLID en nuestros desarrollos.
Como me mencionó alguna vez un maestro: Cualquiera es desarrollador de software, pero somos muy pocos los que seguimos las buenas prácticas.
Y espero que los pocos que somos ahora, con ustedes mis lectores, vallamos siendo más.
Recursos:
Edyn.Dev 