Anemic Domain Model

Este post é uma tradução do Wikipedia.

O Anemic Domain Model é um termo usado para descrever o uso de um software domain model, onde a lógica de negócio é implementada fora dos objetos de domínio.

Resumo
Este pattern foi descrito primeiramente por Martin Fowler, que considera a prática um anti-pattern. Com este pattern, a lógica é tipicamente implementada em classes separadas que transformam o estado dos objetos de domínio. Fowler denomina estas classes externas como transaction scripts (scripts de transação). Este pattern é uma abordagem comum em Enterprise Java Applications, possivelmente encorajado por tecnologias como as versões iniciais do EJB Entity Beans, assim como aplicações .Net que seguem a arquitetura de aplicação de serviços em três camadas, onde tais objetos se enquadram na categoria de "Entidades de Negócios" (embora Entidades de Negócio possam conter comportamento).

Benefícios:
Separação clara entre lógica e dados (programação procedural).


Deficiências:
- Lógica não pode ser implementada de forma verdadeiramente orientada a objeto a não ser que wrappers sejam usados para esconder a estrutura anêmica de dados.
- Violação do encapsulamento e dos princípios de ocultação de informação.
- Necessita de uma camada de negócios separada para conter a lógica localizada em um modelo de domínio. Isto também significa que objetos do modelo de domínio não podem garantir sua correção, porque sua lógica de validação e mutação é colocada em algum local externo (muito provavelmente em múltiplos locais).
- Necessita de um acesso global aos internos das entidades de negócio compartilhadas, aumentando acoplamento e fragilidade.
- Facilita a duplicação de código entre scripts transacionais e casos de uso similares, além de reduzir o reúso de código.
- Necessita de uma camada de serviço quando for compartilhar a lógica de domínio entre diferentes consumidores de um modelo de objeto.
- Torna um modelo menos expressivo e mais difícil de entender.