Estoy estableciendo mis primeros pasos en el diseño impulsado por dominios, compré el libro azul y todo, y me encuentro viendo tres formas de implementar una determinada solución. Para el registro: no estoy usando CQRS o Event Sourcing.
Digamos que una solicitud de usuario entra en la capa de servicio de la aplicación. La lógica de negocios para esa solicitud está (por cualquier razón) separada en un método en una entidad y un método en un servicio de dominio. ¿Cómo debo hacer para llamar a esos métodos?
Las opciones que he reunido hasta ahora son:
- Deje que el servicio de la aplicación llame a ambos métodos
- Use la inyección de método / doble despacho para inyectar el servicio de dominio en la entidad, dejando que la entidad haga lo suyo y luego deje que llame al método del servicio de dominio (o al revés, dejando que el servicio de dominio llame al método en la entidad)
- Genere un evento de dominio en el método de entidad, cuyo controlador llama al servicio de dominio. (El tipo de eventos de dominio del que estoy hablando son: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )
Creo que todos estos son viables, pero no puedo elegir entre ellos. He estado pensando en esto durante mucho tiempo y he llegado a un punto en el que ya no veo las diferencias semánticas entre los tres. ¿Conoces algunas pautas sobre cuándo usar qué?
Respuestas:
El servicio de aplicaciones suele ser un excelente punto de partida para esto, sin embargo, siempre debe intentar cambiar el comportamiento lo más cerca posible de la entidad. El servicio de aplicación desempeña un papel de orquestación y establece el escenario para ejecutar el comportamiento del dominio y, como tal, proporciona todas las dependencias necesarias. Sin embargo, cuando sea posible, debería delegar el comportamiento al modelo de dominio.
Este es un mejor enfoque porque una mayor parte del comportamiento se delega a la entidad o al servicio de dominio. La forma más desacoplada de implementar esto es hacer que una entidad exprese una dependencia en un servicio es como un parámetro del método que proporciona el comportamiento en cuestión.
El patrón de evento de dominio, como explican Udi y también el propio Evans, es bastante versátil y puede aplicarse en una variedad de escenarios. Sin embargo, hay algunas complicaciones que lo acompañan. Primero, debe asegurarse de tener un alcance adecuado dentro del editor de eventos de dominio. La mayoría de las veces, sus controladores de eventos de dominio tendrán dependencias y si está utilizando un contenedor IoC, debe asegurarse de que se inyecten las instancias adecuadas. Por ejemplo, en una aplicación web, el
[ThreadStatic]El atributo es problemático para el alcance. Otra complejidad es la de los límites transcripcionales. Debe tener en cuenta las transacciones, porque si una entidad genera un evento de dominio, pero falla una confirmación posterior a la base de datos, todos los controladores de eventos de dominio necesitarán una forma de revertir, de lo contrario, terminará generando un evento no válido. Sin embargo, si tiene estas bases cubiertas, los eventos de dominio son un gran patrón para encapsular la lógica de dominio dentro de las propias entidades.La diferencia entre el enfoque 2 y 3 depende del caso de uso. Un evento de dominio se aplica cuando desea invocar comportamientos adicionales en respuesta a un evento, que está en tiempo pasado . Esta es una restricción importante, ya que el controlador de eventos de dominio no puede afectar el comportamiento de la entidad. Por otro lado, con el enfoque 2, el servicio inyectado tiene el potencial de afectar el comportamiento porque se declara una dependencia para ese comportamiento en particular.
fuente