Deje que el servicio de la aplicación llame a ambos métodos
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.
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)
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.
Genere un evento de dominio en el método de entidad, cuyo controlador llama al servicio de dominio.
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.