No deje que las palabras de moda de la arquitectura impulsada por eventos lo engañen

Veo muchos términos nuevos como evento de comando, cómputo basado en eventos, etc. introducidos en torno a la arquitectura impulsada por eventos. Permítanme aclarar esto porque esas cosas no existen.

La separación real es la arquitectura basada en eventos frente a la mensajería.

Event Driven Architecture (EDA) se trata de la composición lógica de nuestro flujo de trabajo. Usamos eventos como puntos de control en nuestro flujo de trabajo.

A diferencia del enfoque tradicional, nos enfocamos en los verbos en lugar de los sustantivos. Entonces, los comportamientos en nuestros sistemas, las interacciones entre ellos, las reacciones a la nueva información y los datos en movimiento.

Los eventos son excelentes facilitadores del flujo de trabajo. Representan hechos sobre lo que sucedió. Invertimos el flujo clásico; en lugar de preguntar todo, informamos a todos los interesados. Luego, otros pueden reaccionar y liberar nueva información a través de eventos. Esto ayuda a construir componentes independientes y desacoplados.

Los eventos son mensajes, pero no son el único tipo de mensaje. El segundo más importante es el comando. Se diferencian por la intención. Discutí esto con más detalle en ¿Cuál es la diferencia entre un comando y un evento?. TLDR:

Un comando es una intención de hacer algo. Es dirigido y el administrador puede rechazarlo.

Los eventos son hechos; pueden (y deben) tener múltiples receptores. Sin embargo, los productores de eventos no deben esperar recibir una respuesta.

Comprender esta división es esencial para una buena composición del flujo de trabajo. Por mucho que nos gustaría que nuestra transmisión se disparara y olvidara, a veces necesitamos tener una solicitud explícita para hacer algo. Supongamos que modelamos el flujo de trabajo para que siempre esperemos un evento particular como seguimiento. ¿Nuestro evento es realmente información de transmisión o solo un comando implícito?

Los eventos y los comandos no difieren por definición en cuanto al modo de entrega, ya sean sincrónicos o asincrónicos. La diferencia está en la intención. No es necesario que el evento sea asincrónico o utilice herramientas como Kafka, Rabbit, SQS, etc. Estos son la composición de nuestros flujos, el modelado de la conversación y la estructuración de nuestra arquitectura. Se acerca a la definición original de programación orientada a objetos de Alan Kay.

Ahora hemos llegado a la mensajería. Es un conjunto de modelos como Outbox, Inbox, Competiting Consumers, etc., enfocados a la integración entre nuestras fronteras (módulos, servicios, etc.).

EDA y Messaging son perspectivas de diseño diferentes. Con EDA, usted da forma a la división lógica/conceptual, las interacciones y la apariencia del flujo de su aplicación.

Sabiendo lo que nos gustaría conseguir, podemos bajar un nivel y definir cómo hacerlo. Por ejemplo, cómo lograr garantías como entrega al menos una vez, pedidos estrictos y manipuladores idempotentes. Esto es mensajería; explica cómo gestionar eficazmente la comunicación y forma parte del espacio de soluciones. Sin embargo, sigue siendo agnóstico a una solución técnica específica. Necesitamos seleccionar la herramienta de correo electrónico según el diseño y si es compatible con las plantillas de correo electrónico que hemos elegido para completarla.

El flujo de diseño debería verse así:

¿QUÉ? Describir el flujo de trabajo empresarial y modelarlo utilizando una arquitectura basada en eventos. Esto incluye el flujo de comunicación entre componentes, límites, etc. Grandes herramientas para esto son EventStorming y Event Modeling. ¿CÓMO? Diseñar cómo obtener garantías y definir el flujo técnico esperado utilizando plantillas de mensajería. Ya están establecidos; No hay necesidad de reinventar la rueda. Gregor Hohpe organizó la mayoría de ellos en Enterprise Integration Patterns: Designing, Building, and Deploying Mes...