Cambiando el chip hacia event-driven

Ni falta hace que escriba sobre las ventajas que proporciona el paradigma event-driven en el que los componentes de software reaccionan a eventos a los que se han suscrito previamente. El productor está desacoplado del consumidor y se pueden añadir consumidores conforme se necesitan nuevos tratamientos del evento.

Además, el dominio de los eventos va a crecer y dotar de más significado al código: Se puede tener un evento UserToPurchaseInsurance y un evento InsurancePurchased que semánticamente es más significativo que tener un objeto Insurance con un malvado campo status.

descarga

Event-driven sin broker de mensajería parece un poco engorro. Sin embargo, Spring facilita mucho el trabajo ya que despliega una infraestructura de publicación y suscripción a eventos para los beans registrados en el contexto. Si se da el caso de trabajar en un monolito sin broker de mensajería, los eventos de aplicación de Spring pueden ser un buen inicio para refactorizar algunas partes del código a una arquitectura orientada a eventos.

Este código incluiría 4 dependencias:

  • al proveedor de seguros,
  • al servicio que envía emails,
  • al repositorio y
  • al servicio que roba el coche asegurado:
if (insuranceProvider.purchase(insurance)) {
    sendEmail(insurance);
    persist(insurance);
    stealCar(insurance);
}

Podría convertirse en este otro código que tendría como dependencias el proveedor de seguros y el publicador de eventos. Como se indicó anteriormente, desacoplando productor de los N consumidores.

if (insuranceProvider.purchase(insurance)) {
    publishEvent(InsurancePurchasedEvent.from(insurance));
}

Los puntos de entrada de los consumidores en este caso serían tres listeners:

@Component
public class InsurancePurchasedEmailEventListener {
    @EventListener
    public void sendAnEmail(InsurancePurchased insurancePurchased) {}
}
@Component
public class InsurancePurchasedPersistenceEventListener {
    @EventListener
    public void persistInsurance(InsurancePurchased insurancePurchased) {}
}
@Component
public class InsurancePurchasedThiefEventListener {
    @EventListener
    public void stealTheCar(InsurancePurchased insurancePurchased) {}
}

Esta entrada surge tras haber leído el artículo Spring Events de Baeldung en el que explican exactamente cómo publicar el evento y recuerdan que por defecto los eventos son recogidos por los listeners en el mismo hilo, por lo que la ejecución no continuará hasta que se procese el evento por todos los listeners. Este comportamiento se puede alterar definiendo un bean ApplicationEventMulticaster.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s