pesar de haber estudiadoDomain Driven Design durante mucho tiempo ahora todavía hay algunos conceptos básicos que simplemente descubrí.

arece que cada vez que intento diseñar un @ ridomain layer, Todavía necesito muchoDomain Services o una gruesaApplication Layer, y termino con un grupo de entidades de dominio casi anémicas sin lógica real en ellas, aparte de "GetTotalAmount" y similares. El problema clave es que las entidades no son conscientes de las cosas externas, y es una mala práctica inyectar cualquier cosa en las entidades.

Déjame dar algunos ejemplos

1. Un usuario se suscribe a un servicio. El usuario permanece en la base de datos, se genera y guarda un archivo (necesario para la cuenta del usuario) y se envía un correo electrónico de confirmación.

El ejemplo con el correo electrónico de confirmación se ha discutido ampliamente en otros hilos, pero sin una conclusión real. Algunos sugieren poner la lógica en unaapplication service que obtiene unEmailService yFileService inyectado desde elinfrastructure layer. Pero entonces tendría lógica de negocios fuera del dominio, ¿verdad? Otros sugieren crear unadomain service que obtiene elinfrastructure services inyectado, pero en ese caso necesitaría tener las interfaces deinfrastructure services dentro dedomain layer (IEmailService yIFileService) que tampoco se ve muy bien (porque ladomain layer no puede hacer referencia ainfrastructure layer). Y otros sugieren implementar Eventos de dominio de Udi Dahan y luego hacer que EmailService y FileService se suscriban a esos eventos. Pero eso parece una implementación muy flexible, ¿y qué sucede si los servicios fallan? Por favor, hágame saber cuál cree que es la solución correcta aquí.

2. Una canción se compra en una tienda de música digital. El carrito de compras está vacío. La compra persiste. Se llama al servicio de pago. Se envía un correo electrónico de confirmación.

Ok, esto podría estar relacionado con el primer ejemplo. La pregunta aquí es, ¿quién es responsable de organizar esta transacción? Por supuesto, podría poner todo en el controlador MVC con servicios inyectados. Pero si quiero DDD real, toda la lógica de negocios debería estar en el dominio. Pero, ¿qué entidad debería tener el método de "Compra"? @Song.Purchase()? Order.Purchase()? OrderProcessor.Purchase() (servicio de dominio)? @ShoppingCartService.Purchase() (servicio de aplicación?)

Este es un caso en el que creo que es muy difícil usar una lógica comercial real dentro de las entidades de dominio. Si no es una buena práctica inyectar algo en las entidades, ¿cómo pueden hacer otras cosas además de verificar su propio estado (y el de su agregado)?

Espero que estos ejemplos sean lo suficientemente claros como para mostrar los problemas con los que estoy lidiando.