pesar de ter estudadoDomain Driven Design há muito tempo, ainda existem alguns princípios básicos que eu simplesmente entend

Parece que toda vez que tento criar um ricodomain layer, Ainda preciso de muitosDomain Services ou um grossoApplication Layer, e acabo com um monte de entidades de domínio quase anêmicas sem lógica real nelas, além de "GetTotalAmount" e similares. O principal problema é que as entidades não estão cientes de coisas externas e é uma má prática injetar qualquer coisa nas entidade

Deixe-me dar alguns exemplos

1. Um usuário se inscreve em um serviço. O usuário persiste no banco de dados, um arquivo é gerado e salvo (necessário para a conta do usuário) e um email de confirmação é enviad

O exemplo com o email de confirmação foi discutido intensamente em outros tópicos, mas sem uma conclusão real. Alguns sugerem colocar a lógica em umapplication service que recebe umEmailService eFileService injetado a partir doinfrastructure layer. Mas então eu teria lógica de negócios fora do domínio, certo? Outros sugerem a criação de umdomain service que recebe oinfrastructure services injetado - mas nesse caso eu precisaria ter as interfaces doinfrastructure services dentro dedomain layer (IEmailService eIFileService) que também não parece muito bom (porque odomain layer não pode fazer referência ainfrastructure layer). E outros sugerem implementarventos de Domínio @Udi Dahan e, em seguida, solicitando que o EmailService e o FileService se inscrevam nesses eventos. Mas isso parece uma implementação muito flexível - e o que acontece se os serviços falharem? Deixe-me saber o que você acha que é a solução certa aqui.

2. Uma música é comprada em uma loja de música digital. O carrinho de compras está vazio. A compra é mantida. O serviço de pagamento é chamado. Uma confirmação por email é enviada.

Ok, isso pode estar relacionado ao primeiro exemplo. A questão aqui é, quem é responsável por orquestrar essa transação? Claro que eu poderia colocar tudo no controlador MVC com serviços injetados. Mas se eu quiser DDD real, toda a lógica de negócios deve estar no domínio. Mas qual entidade deve ter o método "Purchase"?Song.Purchase()? Order.Purchase()? OrderProcessor.Purchase() (serviço de domínio)?ShoppingCartService.Purchase() (serviço de aplicativo?)

Este é um caso em que acho muito difícil usar lógica de negócios real dentro das entidades do domínio. Se não é uma boa prática injetar nada nas entidades, como elas podem fazer outras coisas além de verificar seu próprio estado (e o de seu agregado)?

Espero que esses exemplos sejam claros o suficiente para mostrar os problemas com os quais estou lidand