Este post e uma traducao do Wikipedia.O Anemic Domain Model e um termo usado para descrever o uso de um software domain model, onde a logica de negocio e implementada fora dos objetos de dominio.ResumoEste pattern foi descrito primeiramente por Martin Fowler, que considera a pratica um anti-pattern. Com este pattern, a logica e tipicamente implementada em classes separadas que transformam o estado dos objetos de dominio. Fowler denomina estas classes externas como transaction scripts (scripts de transacao). Este pattern e uma abordagem comum em Enterprise Java Applications, possivelmente encorajado por tecnologias como as versoes iniciais do EJB Entity Beans, assim como aplicacoes .Net que seguem a arquitetura de aplicacao de servicos em tres camadas, onde tais objetos se enquadram na categoria de "Entidades de Negocios" (embora Entidades de Negocio possam conter comportamento).Beneficios:Separacao clara entre logica e dados (programacao procedural).Deficiencias:- Logica nao pode ser implementada de forma verdadeiramente orientada a objeto a nao ser que wrappers sejam usados para esconder a estrutura anemica de dados.- Violacao do encapsulamento e dos principios de ocultacao de informacao.- Necessita de uma camada de negocios separada para conter a logica localizada em um modelo de dominio. Isto tambem significa que objetos do modelo de dominio nao podem garantir sua correcao, porque sua logica de validacao e mutacao e colocada em algum local externo (muito provavelmente em multiplos locais).- Necessita de um acesso global aos internos das entidades de negocio compartilhadas, aumentando acoplamento e fragilidade.- Facilita a duplicacao de codigo entre scripts transacionais e casos de uso similares, alem de reduzir o reuso de codigo. - Necessita de uma camada de servico quando for compartilhar a logica de dominio entre diferentes consumidores de um modelo de objeto.- Torna um modelo menos expressivo e mais dificil de entender. Este texto e uma traducao do WikipediaTester driven development e um anti-pattern no desenvolvimento de software. Nao pode ser confundido com Test Driven Development (TDD). Este anti-pattern diz respeito a qualquer projeto de desenvolvimento de software onde a fase de teste e tao longa que os requisitos podem mudar radicalmente durante o teste do software. Requisitos novos ou alterados acabam surgindo como relatorios de bugs. Um software de rastreamento de bugs normalmente nao oferece suporte para lidar com requisitos. Como resultado, ninguem sabe de fato quais sao os requisitos do sistema.Projetos que sao desenvolvidos utilizando este anti-pattern sempre sofrem grandes atrasos. Outro problema frequente e a queda na qualidade do codigo.As causas mais comuns para projetos que acabam sendo executados dessa maneira, sao: A fase de teste comeca muito cedo;Requisitos incompletos;Testadores inexperientes;Desenvolvedores inexperientes;Ma gerencia de projetos.As coisas pioram quando os testadores percebem que nao sabem quais sao os requisitos e, portanto, nao sabem como testar uma mudanca particular no codigo. Desta forma, o onus recai sobre os desenvolvedores de alteracoes para escreverem seus proprios casos de teste. Artigo traduzido de http://sourcemaking.com/design_patternsNa engenharia de software, um design pattern (padrao de projeto) e uma solucao geral para um problema comum de ocorrer no design de software. Um design pattern nao e um projeto concluido que possa ser transformado diretamente em codigo. E