Arquitecturas baseadas en eventos

Notificación de evento

De vez en cuando, algunos enfoques de desarrollo parecen convertirse en un patrón recurrente. Después de un tiempo viendo a las empresas adoptar (a veces sin justificación real) arquitecturas basadas en microservicios, estamos viendo un creciente interés en arquitecturas basadas en eventos.

En esta y otras publicaciones, presentaremos algunos conceptos fundamentales y patrones recurrentes para adoptar «eventos» en el desarrollo de software. Comencemos con los sistemas que emplean notificaciones de eventos.

Comenzando con los fundamentos

Imagine un sistema donde cada vez que un componente (módulo, microservicio, etc.) completa una operación, necesita iniciar una operación asociada en otro componente.

Por ejemplo, considere un sistema de comercio electrónico donde, una vez que se ha confirmado una venta, es necesario activar el proceso de selección y envío de un producto.

Un enfoque simple e ingenuo sería hacer que el primer componente active directamente el segundo componente (llamando a un método, haciendo una solicitud a algún punto final específico, enviando un mensaje de «comando», etc.).

Por exemplo, considere um sistema de e-commerce, onde, após confirmada uma venda, seja necessário disparar o processo de separação e remessa de um produto.

Aún en nuestro ejemplo, podríamos considerar que el sistema de ventas «llamaría» al sistema de envío con una llamada a un punto final o, en un escenario monolítico, al ejecutar un método.

Sin embargo, una solución más compleja y sofisticada sería hacer que el primer componente «active» un mensaje notificando que se ha producido un evento comercial. Correspondería al segundo componente «escuchar» este mensaje y realizar el procesamiento adecuado. En este escenario, el primer componente activaría indirectamente el segundo componente.

Entonces, aún en nuestro ejemplo, podríamos hacer que el sistema de ventas «envíe» un evento con datos relacionados con las ventas que acaban de ocurrir. Mientras tanto, el sistema de envío «escucharía» este evento y haría su trabajo.

Este enfoque tiene el efecto secundario positivo de permitir que otros componentes «escuchen» el mismo evento al permitir que se agregue un procesamiento adicional sin tener que cambiar las partes que ya están funcionando en el sistema.

¿Por qué desarrollar sistemas con notificación de eventos?

Los sistemas distribuidos (incluidos los basados en microservicios) son cada vez más comunes. En estos sistemas, uno de los atributos arquitectónicos más importantes es el bajo acoplamiento.

De acordo con Wikipedia:

En informática, el acoplamiento es la forma y nivel de interdependencia entre módulos de software; una medida de qué tan cercanamente conectados están dos rutinas o módulos de software. Un ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente. En ese caso, el resultado del comportamiento del componente A dependerá del valor del componente B, por lo tanto, están acoplados.

El acoplamiento está comúnmente contrastado con la cohesión. Un bajo acoplamiento normalmente se correlaciona con una alta cohesión, y viceversa. El bajo acoplamiento es frecuentemente una señal de un sistema bien estructurado y de un buen diseño de software.

En términos prácticos, queremos desarrollar, distribuir y mantener sistemas cambiando sus partes sin afectar a las demás. La estrategia de comunicación entre componentes, empleando notificación de eventos, ayuda a desarrollar sistemas con bajo cumplimiento.

En 2002, trabajé en el desarrollo de una solución CAD compleja. Uno de los objetivos del proyecto en ese momento era desarrollar un sistema extremadamente componible (queríamos poder instalar complementos en el sistema, enriqueciendo sus características).

Determinamos que cada vez que se realizaba una operación, o había un cambio de estado, se activaba un evento (en ese momento, lo llamamos activador) en un autobús rudimentario. Los complementos del sistema tenían acceso al bus y podían «identificarse» cuando se activaba un activador (evento) de un tipo particular y luego podían realizar el procesamiento relacionado.

Problemas con los sistemas que emplean notificaciones de eventos

El acoplamiento flojo es genial. Sin embargo, tiene un precio que puede ser muy alto.

Cuando permitimos que los componentes comiencen a escuchar eventos en nuestra aplicación, es fácil perder el control de lo que se realizará.

En el sistema que describí anteriormente, comenzamos a sufrir componentes que realizaron un procesamiento pesado en respuesta a eventos, y la aplicación a menudo perdió capacidad de respuesta.

Además, los sistemas distribuidos basados en notificaciones de eventos hacen que algunos tipos de operaciones comunes (como las transacciones) sean difíciles de implementar y especialmente de monitorear.

Es importante tener en cuenta que es posible lograr un buen nivel de bajo acoplamiento simplemente implementando enfoques asincrónicos para la activación activa (como enviar comandos de un componente a otro utilizando algún mecanismo de mensajería).

Concluyendo

Los sistemas basados en notificaciones de eventos tienden a tener una evolución fácil. Sin embargo, debe ser consciente de la «evolución» de los flujos de ejecución para compensar esta «complejidad» simplificando la implementación de las operaciones de dominio.

Los sistemas basados en eventos presentan desafíos nuevos y complejos para monitorear la implementación (tema para otra publicación).

¿Tiene alguna experiencia desarrollando sistemas que adopten eventos de notificación?

Más publicaciones en la serie Arquitecturas baseadas en eventos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *