EDA
Una arquitectura event-driven (EDA) es un estilo de diseño que se basa en la producción, detección y reacción a eventos. Un evento es un cambio de estado significativo en el sistema o en el entorno que puede ser notificado a otros componentes interesados. Una arquitectura event-driven permite una mayor desacoplamiento, escalabilidad y resiliencia entre los componentes del sistema, así como una mejor adaptabilidad a los cambios y a las necesidades del negocio.
Sin embargo, una arquitectura event-driven también puede tener sus desafíos y riesgos, especialmente si no se aplica una buena gestión de los dominios y los boundaries. Un dominio es un conjunto de conceptos, reglas y procesos relacionados con un aspecto del negocio o del problema que se quiere resolver. Un boundary es una frontera lógica que separa y protege un dominio de otros dominios o de influencias externas. Un buen diseño de dominios y boundaries facilita la comprensión, el mantenimiento y la evolución del sistema, así como la comunicación y la colaboración entre los equipos de desarrollo.
Uno de los problemas más comunes que puede surgir en una arquitectura event-driven es el llamado “Big ball of mud”. Este término se refiere a un sistema que carece de una estructura clara y coherente, que se ha ido construyendo de forma ad hoc y sin seguir ningún principio o patrón de diseño. Un “Big ball of mud” es difícil de entender, de modificar y de extender, y puede provocar errores, inconsistencias y pérdidas de rendimiento.
¿Cómo podemos evitar que nuestra arquitectura event-driven se convierta en un “Big ball of mud”?
Aquí te presentamos algunas recomendaciones y ejemplos:
- Define y documenta los dominios y los boundaries de tu sistema, y asegúrate de que los eventos que se producen y se consumen en cada dominio sean relevantes, consistentes y completos. Por ejemplo, si tienes un dominio de facturación, los eventos que se generen y se reciban en ese dominio deberían estar relacionados con la facturación, y no con otros aspectos como el inventario o el envío.
- Utiliza patrones de diseño que te ayuden a organizar y gestionar los eventos de forma eficiente y segura, como el event sourcing, el CQRS, el saga o el event notification. Por ejemplo, el event sourcing consiste en almacenar el estado de un dominio como una secuencia de eventos, lo que permite reconstruir el estado en cualquier momento, realizar consultas históricas o revertir cambios no deseados.
- Establece y respeta las reglas y los protocolos de comunicación entre los componentes del sistema, y evita las dependencias innecesarias o las interacciones complejas. Por ejemplo, puedes usar un bus de eventos, un broker o un stream para facilitar la publicación y la suscripción de eventos, y aplicar técnicas como el enrutamiento, el filtrado o la transformación de eventos para optimizar el flujo de información.
- Implementa mecanismos de control de calidad, de monitorización y de trazabilidad de los eventos, y asegúrate de que los eventos sean identificables, auditable y verificables. Por ejemplo, puedes usar un identificador único, un sello de tiempo y un esquema para cada evento, y emplear herramientas como el logging, el tracing o el testing para detectar y resolver problemas.
Siguiendo estas recomendaciones, podrás aprovechar los beneficios de una arquitectura event-driven sin caer en el “Big ball of mud”. Recuerda que el diseño de una arquitectura event-driven requiere un análisis cuidadoso de los requisitos, las expectativas y los objetivos del sistema, así como una revisión y una mejora continua del mismo.