Oi Diego, a discussão já está aberta a um tempo, mas gostaria de acrescentar. Nem sempre é possível deixar o modelo não anêmico. Isso se dá muito pela estrutura da linguagem Java.
Pense o seguinte, se você quer a Nota Fiscal de uma determinada compra, como você faria para obter a nota?
compra.obterNotaFiscal() ou notaFiscalDao.buscaPorCompra(numeroPedido)?
O primeiro modelo seria muito mais natural correto? Porém se imaginarmos o que será necessário para a entidade compra obter a nota fiscal, iremos lembrar que é preciso ir no banco de dados, e para ir no banco, é preciso conexão, transação, datasource, etc.. Imagine colocar tudo isso dentro da classe Compra? Estaríamos fazendo uma salada só na classe e ao tentar torná-la não anêmica estaríamos quebrando a regra de responsabilidade. A Compra teria que ter conexão ou no caso de JPA Entity Manager. O que não tem nada haver com a Compra em si.
public class Compra {
@PersistentContext
private EntityManager manager;
private NotaFiscal notaFiscal;
// demais atributos
}
Por essa razão, nossas entidades são praticamente modelos anêmicos, mas quando possível e quando temos lógicas que não dependem do banco, podemos utilizar a classe para tal, como no exemplo que o Rodolfo colocou.
Por que falei que o Java quase nos obriga a isso? Porque em Rails/Javascript e outras linguagens dinâmicas, podemos criar classes que possuem o modelo que ela representa e em outra classe, adicionar as funcionalidades desejadas aquela entidade. Não fazemos tudo na classe Compra direto, por exemplo, essa classe teria apenas o modelo e ficaria mais enxuta, mas ainda assim seria possível fazer compra.obterNotaFiscal() e esse método ir ao banco sem "sujar" a classe com objetos de persistencia.
No mais, acabamos deixando nosso modelo um pouco anêmico, mas separamos as responsabilidades nos Services e DAOs do sistema.
