Martin Fowler considera o Anemic Domain Model como um antipadrão.

Rolando o modelo de persistência como o modelo de domínio parece severamente desligado também devido aMississch de Impedância Relacional de Objeto. Para fins de persistência e normalização, tendemos a dividir as classes em pequenas partes muito pequenas, o uso de métodos de tapas nessas classes é tolo. Além disso, persistência raramente muda, mas a lógica de negócios muda um pouco.

Então, precisamos de um DomainModel que se baseie no modelo de persistência (em vez de ser um e o mesmo). Este modelo de domínio conterá propriedades e método da lógica de negócios.

Mas agora esses Modelos de Domínio ainda estão por trás do serviço e, para expô-los ao mundo externo, precisamos convertê-los para DTOs.

Nós estamos fazendo muitos mapeamentos aqui.

Persistência ao modelo de domínioPara converter o Modelo de Domínio em DTOs para passar entre serviços

Não termina aí, já que o DTO pode precisar ser mapeado no ViewModel.

Tudo isso e o problema de duplicar a lógica de validação ainda não desaparece, porque o cliente quer validação em tempo real. ViewModel não sabe nada sobre validação, então em um SPA, por exemplo, você é forçado a reescrever a lógica de validação novamente, no lado do cliente (geralmente em javascript).

Além disso, os serviços são, por natureza, sem estado (orientados por mensagem ou RPC), portanto, estamos fazendo todos esses mapeamentos, entre Persistência, para OO e depois para Procedural, para que benefício? Como você justificaria o custo em termos práticos da maior parte do orçamento de TI?

Eu entendo como ter DDD completo, com Raízes Agregadas, Modelos de Domínio, etc., seria "legal", mas como você pode justificar o custo e o impacto na produtividade dev?

anti-padrão (ou antipadrão) é um padrão usado em operações sociais ou de negócios ou engenharia de software que pode ser comumente usado, mas é ineficaz e / ou contraproducente na prática

E se assim for, o DDD e o Rich Domain Model não se encaixariam na definição de antipadrão acima do modelo de domínio "Lean". Desculpe, eu desprezo a palavra carregada, "anêmica".

Mantendo o Modelo de Domínio, "Lean", você permite que ele seja compartilhado sem violar o "Princípio de Dependência Abstrata", "Não Repita a Si Mesmo" e o demorado, tedioso e propenso processo de mapeamento de um portador de dados para outro. e qualquer Teste de Unidade associado que esteja em cima disso (a menos que você esteja pensando em fazer mapeamento sem testes unitários e esperar pelo melhor).