Artículo de Jorge Berjano, Arquitectura Software en decide4AI.
Cada día generamos millones de datos a través de nuestras acciones e interacciones con diferentes dispositivos. En esta era hiperconectada los ecosistemas tecnológicos han tenido que ir evolucionando para adaptarse a este nuevo paradigma de datos masivos, que los antiguos sistemas no podían soportar ni procesar.
A raíz de la necesidad de las compañías de contar con una alta disponibilidad de los datos y poder crear y gestionar productos y servicios de manera escalable y rápida, han ido apareciendo diferentes tipos de arquitecturas y patrones software que ayudan a alcanzar estos objetivos. Veamos los principales paradigmas:
Arquitectura de Microservicios
La arquitectura de microservicios es un método de desarrollo de aplicaciones software que funciona como un conjunto de pequeños servicios que se ejecutan de manera independiente y autónoma, proporcionando una funcionalidad de negocio completa.
Los microservicios han creado infraestructuras IT más adaptables y flexibles. Porque si se quiere modificar solamente un servicio, no es necesario alterar el resto de la infraestructura. Cada uno de los servicios se puede desplegar y modificar sin que ello afecte a otros servicios o aspectos funcionales de la aplicación.
Los microservicios se comunican entre sí a través de APIs, y cuentan con sistemas de almacenamiento propios, lo que evita la sobrecarga y caída de la aplicación. Permiten escalar de forma horizontal los subsistemas que lo necesiten y facilitan la integración y el despliegue continuo (CI/CD).
Command-query reponsibility-segregation (CQRS)
El CQRS se puede enfocar como un patrón de diseño para codificación o como un patrón arquitectónico en un entorno de microservicios, que aplica el principio de separación de los comandos (peticiones por parte del usuario u otro sistema para realizar una operación de negocio, que evolucione el sistema de un estado a otro) y las consultas.
Pueden tener varios subsistemas especializados de consulta o de comandos, donde como su nombre indica, unos son responsables de los comandos y otros de las consultas.
Cada uno de los subsistemas tiene un diseño, mecanismo de persistencia y modelo de información diferentes, optimizados para las tareas que deben afrontar. Se pueden escalar de manera independiente y usan cachés y precocinado de datos para ofrecer una respuesta más rápida. Como contrapartida, como suele haber datos duplicados, es más complejo mantener la integridad de los mismos.
Event Sourcing (ES) y arquitectura dirigida por eventos (EDA)
Los eventos son cambios de estado significativos en un sistema, por ejemplo, el paso de “tarea en proceso” a “tarea finalizada”. Este evento que se ha producido desencadena la emisión de un mensaje (notificación de evento) que se publica, propaga, detecta y consume en otras aplicaciones dentro de la arquitectura. La arquitectura dirigida por eventos o en inglés Event-Driven Architecture (EDA) es un paradigma de arquitectura de software que promueve la producción, detección, consumo y reacción a los eventos.
Un sistema dirigido por eventos está formado por aplicaciones y sistemas que transmiten eventos en tiempo real entre componentes y servicios de software. Hay componentes que son emisores de eventos, consumidores de eventos y canales de eventos. Los emisores detectan, recogen y transfieren eventos, los consumidores aplican una reacción cuando se presenta un evento, y los canales de eventos son las vías de transmisión de eventos entre los emisores y los consumidores.
Los sistemas de mensajería de eventos son una alternativa más flexible que la comunicación mediante peticiones de APIs RESTful. Se trata de comunicar asíncronamente el ecosistema de microservicios usando colas de mensajes que funcionan como depósitos (buffers) se evita la saturación en los servicios que consumen los eventos, solucionando problemas de contrapresión (backpressure). Para una mayor velocidad en este tipo de arquitectura las consultas se hacen contra bases de datos intermedias relacionales, con datos preparados.
Es muy frecuente recurrir al uso de programación reactiva (Reactive Programming) cuando se trabaja con colas de mensajes lo cual facilita de una manera significativa el desarrollo del software.
Todos los eventos se guardan de manera que existe un historial de todas las modificaciones en los sistemas. Además, se pueden utilizar herramientas de análisis para ver cómo funciona el flujo de eventos, los contenedores, servicios o colas de mensajes para detectar fallos o ineficiencias.
Diseño dirigido por dominio (DDD)
Los sistemas que aplican los paradigmas anteriores suelen hacer uso de las prácticas expuestas en el diseño dirigido por dominios
El diseño dirigido por dominio o en inglés domain-driven design (DDD) es un enfoque de desarrollo software que enfatiza la conexión entre la implementación y el modelo de negocio. En él los distintos subsistemas tienen correspondencia directa con los conceptos que maneja el cliente y sus expertos en negocio, promoviendo un lenguaje ubicuo para facilitar más el entendimiento entre las partes. Su objetivo es acelerar el desarrollo de proyectos de software que deben lidiar con dominios complicados.
Conclusiones
Es indudable el incremento de aplicaciones que dan todo tipo de servicios a nivel global como las plataformas de venta online, redes sociales, contenidos audiovisuales en streaming y un sinfín de aplicaciones que existen y están por llegar, para las cuales es inviable el antiguo paradigma de aplicación monolítica.
El foco de estos nuevos paradigmas arquitectónicos es dar una solución óptima a los nuevos retos con los que se encuentra el desarrollo de software en la actualidad, donde es de crucial importancia la ausencia de demora en la interacción del usuario con las aplicaciones para conseguir una completa satisfacción. Esto, unido a la gran cantidad de usuarios y datos que se manejan, hacen necesarias nuevas estrategias para abordar este objetivo.
No es extraño que en los últimos años hayan surgido nuevos modelos que rompen con los planteamientos preexistentes, no solo a nivel de arquitectura sino también a nivel metodológico. Hay quien lo puede interpretar como modas pasajeras, pero creo que es más objetivo verlo como una evolución hacia algo que va a mejorar y facilitar el desarrollo de software en el futuro.
