Patrón de diseño controlado por el dominio - accediendo al repositorio desde el dominio

Question

He estado trabajando para aplicar el patrón de diseño impulsado por dominio a nuestra aplicación web. Uno de los problemas con los que nos hemos encontrado es evitar tener que usar un repositorio dentro de una entidad.

Por ejemplo, tenemos algunas entidades cuyos métodos activarán un correo electrónico. Entonces, debemos tener acceso a la plantilla de correo electrónico (almacenada en la base de datos), así como también crear un nuevo registro de correo electrónico en la tabla de cola de la base de datos. Actualmente estamos violando el patrón al acceder a los repositorios en estas instancias.

¿Deberíamos estar utilizando una capa de "servicio" o "aplicación" en estos casos (tenemos muchos de ellos)? ¿Hay una mejor manera de evitar este problema?

Answer 1

Sí, recomendaría crear un servicio para realizar el envío del correo electrónico. Puede crear una interfaz para interactuar con el servicio en el mismo proyecto que el modelo de dominio, pero proporcionar la implementación del servicio en un proyecto separado para que no haya una dependencia fuerte del modelo al servicio. La dependencia se invierte, del servicio al modelo. Esto también crea una mejor configuración para implementar pruebas unitarias para garantizar que se llame a su servicio bajo las circunstancias que deberían ser, ya que ahora podrá burlarse del servicio en las pruebas de su unidad.

Lo único que queda por hacer es asegurarse de que su servicio se inyecte cada vez que se cree uno de estos tipos de objetos. Por lo tanto, diferirá la creación de objetos en el repositorio. O mejor aún, use un marco de inyección de dependencia para resolver la dependencia por usted.

Answer 2

El dominio debe ser persistente ignorante. No debe "hablar con el repositorio" desde adentro.

En su escenario - I would raise domain event (por ejemplo, "El cliente está comprando algo") y gestiona el envío de correo electrónico desde el exterior.