Llevo un par de posts dedicados a construir modelos de dominio más ricos, poniendo como ejemplo el uso de clases en lugar de tipos enumerados y explicando cómo pasar lógica de los servicios a las entidades para obtener un dominio más compacto.

En el último post, al explicar las ventajas e inconvenientes de encapsular la lógica en entidades, indicaba que un problema potencial era que aumentábamos el acoplamiento entre diferentes componentes del sistema.

Al pasar lógica a las entidades, había ocasiones en que teníamos que pasarle a las entidades servicios como argumentos de métodos para que pudiesen utilizarlos, quedando acoplados entre sí la entidad y el servicio recibido como argumento. Concretamente, en el ejemplo que veíamos para la confirmación de un pedido, acabábamos con un método Confirm con este aspecto:

public class Order
{
  // Otros métodos, propiedades, etc.
 
  public void Confirm(Carrier carrier, IShippingCostCalculator calculator) 
  {
    // ...
  }
}

Supongamos que ahora el proceso de confirmación de pedido implica más pasos, por ejemplo enviar un email de confirmación al cliente y reservar el stock de las unidades pedidas. Esa lógica de coordinación podríamos dejarla en un servicio externo o, como vimos en el post anterior, incluirla en el método Confirm añadiendo parámetros para representar un IEmailSender y un IWarehouseService. Lo malo es que nuestro método Confirm empezaría a mezclar muchas responsabilidades y a tener una lista de parámetros un tanto desagradable.

OJO: No perdáis de vista que esto es sólo un ejemplo, en la vida real sería discutible que esos procesos quisiéramos hacerlos en el mismo momento de confirmar el pedido y que quisiéramos hacerlos dentro del mismo bounded context que la confirmación, pero para el ejemplo vamos a asumir que es así.

Eventos de dominio

Los eventos de dominio no son algo precisamente novedoso. La primera vez que leí sobre ellos fue en este post de Udi Dahan del 2009 que os recomiendo que leáis detenidamente. La idea es representar cosas que han sucedido en nuestro dominio y poder detectar cuándo se producen los eventos para actuar en consecuencia.

Existen varias formas de implementarlos, pero lo más normal es tener clases que representen cada evento de dominio y una fachada estática que nos permita «disparar» los eventos.

En una versión muy minimalista podríamos tener algo así:

// Interface marcador para eventos de dominio
public interface IDomainEvent {}

// Interface marcador para manejadores de eventos
public interface IDomainEventListener {}

// Interface concreto para manejar un evento
public interface IDomainEventListener<T> : IDomainEventListener where T : IDomainEvent
{
  void Handle(T @event);
}

// Fachada estática para disparar los eventos
public static class DomainEvents
{
  private static readonly List<object> listeners = new List<object>();
 
  public static void Register(IDomainEventListener handler)
  {
     listeners.Add(handler);
  }
 
  public static void Raise<T>(T @event) where T : IDomainEvent
  {
    var thisEventListeners = listeners.Where(x => x is IDomainEventListener<T>).ToArray();
   
    foreach (var handler in thisEventListeners)
      handler.Handle(@event);
  }
}

La implementación de la clase DomainEvents es muy simple y está pensada para entender el ejemplo, pero no es una implementación apta para producción. Tiene varias limitaciones, la más importante de ellas es que tiene problemas en un entorno multihebra. Si quieres ver una implementación más completa, échale un vistazo al post de Udi Dahan.

Una vez que tenemos implementada esta pequeña infraestructura, podríamos reconvertir nuestro método Confirm de la clase Order:

public class Order
{
  public void Confirm(Carrier carrier, IShippingCostCalculator shippingCostCalculator)
  {
    this.carrier = carrier;
    this.shippingCost = calculator.CalculateShippingCost(carrier, deliveryAddress.ZipCode, TotalAmount);
    this.status = OrderStatus.Confirmed;  

    DomainEvents.Raise(new OrderConfirmed(this));
  }
}

Ahora, además del proceso que hacíamos anteriormente, cuando confirmamos el pedido lanzamos un evento para indicar que el pedido ha sido confirmado. Este evento tiene el siguiente aspecto:

public class OrderConfirmed : IDomainEvent
{
  public readonly Order Order;

  public OrderConfirmed(Order order)
  {
    Order = order;
  }
}

Los eventos siempre tendrán nombres en pasado puesto que representan cosas que ya han sucedido. Ahora, podríamos definir manejadores de eventos para gestionarlos:

public class EmailSender : 
  IDomainEventListener<OrderConfirmed>,
  IDomainEventListener<OrderCancelled>
{
  public void Handle(OrderConfirmed @event)
  {
    // Enviar email de confirmación
  }
  
  public void Handle(OrderCancelled @event)
  {
    // Enviar email de cancelación
  }
}

public class Warehouse : 
  IDomainEventListener<OrderConfirmed>,
  IDomainEventListener<OrderCancelled>
{
  public void Handle(OrderConfirmed @event)
  {
    // Reservar stock de los productos incluidos en el pedido
  }
  
  public void Handle(OrderCancelled @event)
  {
    // Liberar el stock reservado para el pedido
  }
}

He incluido dos manejadores de eventos, EmailSender y Warehouse, uno encargado del envío de emails y otro de la gestión del almacén. Cada uno de ellos responde a dos eventos el de OrderConfirmed lanzado cuando se confirma un pedido, y un hipotético OrderCancelled que se lanzaría en caso de que el cliente decidiera cancelar el pedido.

Lo he hecho así para remarcar algo que es muy importante: un manejador de eventos encapsula comportamiento relacionado con un concepto de nuestro dominio y para ello es habitual que tenga que escuchar varios eventos.

Si hubiésemos implementado esto con un servicio, tendríamos concentrada en un método la lógica relacionada con un caso de uso (confirmar un pedido). Al utilizar eventos de dominio, estamos encapsulando la lógica relativa a un concepto (el almacén o el envío de emailings).

La ventaja de este diseño es que nos permite añadir nuevo comportamiento en el dominio sin cambiar lo que ya existe. Sólo necesitamos registrar nuevos manejadores de eventos que escuchen los eventos necesarios para implementar la funcionalidad requerida.

Sobre acoplamiento y dependencias

En este ejemplo, el evento encapsula la clase Order completa, cosa que, sinceramente, no me acaba de gustar y habría que intentar evitar porque va a introducir una dependencia entre los manejadores del evento y la clase Order, pero a veces es lo más cómodo.

Pese a disparar el evento, la parte de cálculo de los gastos de envío sigue realizándose en la clase Order porque no queremos tener que exponer hacia el exterior la posibilidad de modificar el estado interno de la clase Order para que pueda mantener su invariante. Esto es importante: el uso de eventos de dominio no implica que todo haya que hacerlo mediante eventos de dominio.

Notas finales

Los eventos de dominio son una técnica que utilizo bastante para construir modelos más ricos. La facilidad con que se puede añadir nuevo comportamiento al dominio a base de enganchar nuevos manejadores es algo que se agradece mucho y que, sobre todo, permite no tocar el código que funciona cuando tenemos que hacer cosas nuevas (¿a alguien le suena el Open /Close Principle?).

Pese a todo, también tienen algunas pegas que debemos tener en cuenta:

Por una parte, estamos introduciendo una dependencia implícita entre nuestras entidades y la clase estática DomainEvents y, como toda dependencia implícita, es algo oscuro que puede dificultar la comprensión del código, ya que sólo viendo el API de la entidad no podemos saber si se lanzará o no un evento de dominio. Hay gente que además lo ve como un inconveniente a la hora de testear las entidades, pero la verdad es que existen técnicas sencillas para poder testearlas y no suele ser un problema.

Por otra parte, y como siempre que se introducen eventos, estamos ganando flexibilidad a costa de complicar el flujo de la aplicación. Lo que antes era una serie de sentencias que se ejecutaban linealmente, ahora es un evento que se dispara y que será gestionado por manejadores que pueden estar dispersos por la aplicación y de los que además (y esto es muy importante tenerlo en cuenta), no podemos garantizar el orden en que se ejecutan, por lo que deberán ser completamente independientes unos de otros.

En definitiva, los eventos de dominio pueden ayudarnos a encapsular lógica en nuestro modelo de dominio de una forma flexible y fácil de extender, pero como todo, es importante saber qué implicaciones tiene utilizarlos para poder tomar la decisión correcta sobre cuándo y cómo utilizarlos.