Get best of the week

¿Por qué Event Sourcing es el antipatrón para la interacción de microservicios?

Hola de nuevo. En marzo, OTUS lanza la próxima transmisión del curso de Software Architect . En previsión del inicio del curso, hemos preparado una traducción de material útil para usted.



Recientemente, las arquitecturas controladas por eventos (arquitecturas controladas por eventos) y, en particular, el aprovisionamiento de eventos (la generación de eventos) se han generalizado. Esto se debe al deseo de crear sistemas modulares sostenibles y escalables. En este contexto, a menudo se usa el término "microservicios". En mi opinión, los microservicios son solo una de las formas de implementar un " contexto limitado ". Es muy importante definir correctamente los límites de los módulos, y el diseño estratégico , descrito por Eric Evans en Diseño dirigido por dominio, ayuda en esto . Le ayuda a identificar / detectar módulos, límites ("contexto restringido") y describir cómo estos contextos se relacionan entre sí (mapa de contexto, ContextMap).

Eventos de dominio como base de un solo idioma


Aunque esto no se indica explícitamente en el libro de Eric Evans, los eventos de dominio contribuyen muy bien a los conceptos DDD. Prácticas como la tormenta de eventos Alberto Brandolini cambia el enfoque de los eventos desde el nivel técnico al organizacional y comercial. Aquí no estamos hablando de eventos de la interfaz de usuario, como hacer clic en un botón (ButtonClickedEvent), sino de eventos de dominio que forman parte del área temática. Son comentados y entendidos por expertos en el área temática. Estos eventos son los conceptos principales y ayudan a formar un solo idioma (lenguaje ubicuo ), con el que todos los participantes (expertos en la materia, desarrolladores, etc.) estarán de acuerdo.

Eventos de dominio utilizados para comunicarse entre contextos


Los eventos de dominio se pueden usar para interactuar entre contextos restringidos. Supongamos que tenemos una tienda en línea con tres contextos: Pedido (entrega), Entrega (entrega), Factura (cuenta).

Considere el evento "Orden aceptada" en el contexto de la Orden. El contexto de la factura, así como el contexto de entrega, están interesados ​​en rastrear este evento, ya que este evento desencadena algunos procesos internos en estos contextos.

El mito de la conectividad débil


El uso de eventos de dominio ayuda a desarrollar módulos acoplados libremente. Los módulos individuales pueden no estar disponibles temporalmente. Pero para un evento de dominio, no es absolutamente importante si están disponibles o no, ya que el evento solo describe lo que sucedió en el pasado. Otros módulos deciden cuándo procesar el evento. Obtiene un sistema flexible por defecto.

Además del desacoplamiento de tiempo, los eventos de dominio le brindan otra ventaja: el contexto del pedido no necesita saber que el contexto de las facturas y la entrega escucha sus eventos. De hecho, ni siquiera necesita saber que existen estos contextos.

Es genial, pero la dificultad radica en decidir qué datos almacenar en el evento.

La respuesta simple: ¡Abastecimiento de eventos!


Los eventos son útiles, entonces, ¿por qué no usarlos al máximo? Esta es la idea principal de Event Sourcing . Usted almacena el estado de la unidad no mediante la actualización de sus datos (CRUD), sino mediante el uso de una secuencia de eventos.
Además del hecho de que puede reproducir eventos y obtener el estado, hay otra característica de Event Sourcing: obtiene un registro de auditoría completo de forma gratuita. Por lo tanto, cuando se requiera dicho registro, al elegir una estrategia de almacenamiento, asegúrese de prestar atención a Event Sourcing.

Event Sourcing es solo un nivel de almacenamiento


Puede parecerle extraño que cambie inmediatamente de eventos de dominio a almacenamiento, ya que, obviamente, estos son conceptos de diferentes niveles.

... y aquí está mi punto: ¡El Abastecimiento de eventos es una solución local utilizada en un solo contexto limitado! ¡Los eventos de aprovisionamiento de eventos no deben llevarse al mundo exterior! Otros contextos limitados no necesitan saber cómo se almacenan los datos de cada uno y, por lo tanto, no importa si algún contexto utiliza el Abastecimiento de eventos.

Si usa Event Sourcing a nivel mundial, entonces revela su nivel de almacenamiento.

El método de almacenamiento de datos se convierte en su API pública. Cada vez que realice cambios en el nivel de almacenamiento, tendrá que lidiar con un cambio en la API pública.

Estoy seguro de que todos estarán de acuerdo en que es malo cuando varios contextos limitados comparten datos en una base de datos (relacional) debido a la conectividad resultante. Pero, ¿cómo es esto diferente de Event Sourcing? Nada. No importa si usa eventos compartidos o tablas compartidas en la base de datos. En ambos casos, comparte los detalles de almacenamiento.

Hay una salida


Sigo argumentando que los eventos de dominio son ideales para interactuar entre contextos limitados, pero estos eventos no deberían estar relacionados con los eventos que se utilizan para el abastecimiento de eventos.

La solución propuesta es muy simple: no importa qué enfoque use para almacenar datos (CRUD o Event Sourcing), publica eventos de dominio en el almacén de eventos global. Estos eventos representan la API pública de su contexto. Cuando utiliza Event Sourcing, almacena los eventos de Event Sourcing en su tienda local, accesibles solo para este contexto limitado.

Libertad de Elección


Tener eventos de dominio separados en la API pública le permite modelarlos de manera flexible. No está limitado a un modelo predefinido por Event Sourcing.

Hay dos opciones para trabajar con "eventos del mundo real": un servicio de protocolo abierto y un idioma público (servicio de host abierto, idioma publicado) o un cliente / proveedor.

Servicio con un protocolo abierto y un idioma público (servicio de host abierto, idioma publicado)


Solo se publica un evento de dominio que contiene todos los datos que otros contextos limitados pueden necesitar. En la terminología DDD, esto se puede llamar un servicio de host abierto y un idioma publicado.



El inicio del evento en el mundo real “orden aceptado” conduce a la publicación de uno OrderAccepted caso de dominio . La carga útil de este evento contiene todos los datos de pedidos que otros contextos restringidos podrían necesitar ... por lo que esperamos que los contextos de Factura y Entrega encuentren toda la información que necesitan.

Cliente / Proveedor


Para cada consumidor, se publican eventos separados. Es necesario coordinar los modelos de cada evento con un solo consumidor; no es necesario determinar un modelo compartido común. DDD llama a esta relación Cliente / Proveedor.



La ocurrencia de eventos del mundo real "Pedido aceptado" lleva a la publicación de eventos individuales para cada uno de los consumidores: InvoiceOrderAcceptedy DeliveryOrderAccepted. Cada evento de dominio contiene solo los datos necesarios para el contexto del destinatario.

No quiero discutir los pros y los contras de estos enfoques ahora. Solo quiero llamar la atención sobre el hecho de que puede elegir la cantidad de eventos de dominio y los datos que almacenan.

Esta es una ventaja que no debe subestimar, ya que puede decidir cómo desarrollar la API de su contexto limitado sin estar vinculado a los eventos de aprovisionamiento de eventos.

Conclusión


La exposición de piezas de almacenamiento es un antipatrón bien conocido. Hablando de almacenamiento, pensamos principalmente en tablas de bases de datos, pero vimos que los eventos utilizados para el abastecimiento de eventos son solo otra forma de almacenar datos. Por lo tanto, darlos también es un antipatrón.


Traducción: "un buen desarrollador como un hombre lobo teme a las balas de plata".

Event Sourcing es un enfoque poderoso si se usa correctamente (localmente). A primera vista, parece que para las arquitecturas orientadas a eventos esto es una bala de plata, pero si observa de cerca, puede ver que este enfoque puede conducir a una conexión fuerte ... que por supuesto no desea.

Referencias


Además de mi experiencia personal, recibí mucha inspiración de varios artículos y conferencias. Me gustaría mencionar la presentación de Eberhard Wolff "Arquitectura e implementaciones basadas en eventos con Kafka y Atom" (arquitectura e implementación de eventos usando Kafka y Atom). Especialmente sobre Event Sourcing y qué eventos son , lo cual es muy relevante en el contexto de esta publicación. El ejemplo de la tienda en línea también se inspiró en esta charla.

Si desea más información, puede consultar estos recursos:


: « : ».

More articles:


All Articles