Controladores de eventos de dominio: ¿deberían usarse para las preocupaciones de la capa de aplicación?

Question

Al implementar eventos de dominio, los controladores de eventos solo se deben usar para problemas de dominio; algo que discutirías con los expertos en negocios, o ¿están abiertos para ser utilizados por cualquier cosa que tenga interés en el modelo de dominio?

Esto probablemente se explica mejor con un ejemplo simple, considere una aplicación de calendario para programar el trabajo para los empleados.

Podríamos tener los siguientes eventos de dominio ...

AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved

Tenemos controladores de estos eventos, por ejemplo, cuando una cita se traslada a un tiempo fuera de los empleados Horas de trabajo configuramos una bandera de advertencia.

Por supuesto, hay inquietudes sobre aplicaciones que están interesadas en estos eventos, p. cuando se agrega una Cita al calendario, debemos agregarla a la Unidad de trabajo para que podamos enviar los cambios más tarde.

¿Deberían estas aplicaciones ser consumidores de los eventos de dominio, o deberíamos plantear y manejar eventos de sistema separados en su lugar?

Answer 1

Existen dos formas bien establecidas de utilizar eventos en una solución DDD.

El primero se basa en el articles about events de Udi Dahan. Si no los ha leído ya, lo recomiendo encarecidamente. En resumen, dice que publica sus eventos usando la clase estática además de comportamiento normal de estilo ORM. Para agregar un pedido a la colección de pedidos del cliente y, publique el evento. Debido a que el comportamiento de su dominio se ejecuta dentro de un alcance de transacción, también lo son los manejadores de eventos. También puede encontrar allí y consejos para no adjuntar objetos manualmente a una Unidad de trabajo. Se deben crear nuevas raíces agregadas invocando el comportamiento en las existentes.

Hay otra opción promovida por Greg Young. Se basa en el aprovisionamiento de eventos que básicamente utiliza eventos como medio de estado persistente. En este enfoque, sus raíces agregadas usualmente utilizan cierta infraestructura (por ejemplo, clase de raíz agregada base) para aplicar eventos. Aplicar invoca un controlador de eventos en la clase de raíz agregada y publica este evento en un bus (cualquiera que sea la implementación de bus que utilice).

Answer 2

Si se refiere a problemas transversales, se verá obligado a utilizarlo de todos modos si la lógica de su aplicación así lo requiere. Por lo tanto, se mezclará con otro código de procesamiento de eventos.

Pero si necesita hacer varias cosas independientes cuando se produce el evento de su dominio, es mejor utilizar controladores de eventos separados (consulte el principio de Separación de preocupaciones).

En el primer caso, dicho sea de paso, intente evitar mezclar lógica de dominio con lógica de procesamiento de eventos (infraestructura). Infraestructura izquierda/código de preocupaciones transversales en controladores de eventos que llaman a métodos de dominio. Mover el código de dominio dentro de los métodos de los objetos de dominio.