Opa! Valeu pela otima explicacao, Gabriel! 
Um modelo de domínio rico tem algumas vantagens, e a primeira e mais importante de todas é que vc consegue representar, de forma realmente OO, os requisitos do seu sistema, e as funcionalidades dos seus objetos. Se voce parar pra pensar bem, um modelo de objetos anemico (feito de VOs, como no seu caso) é programação procedural, e um objeto que só tem getters e setters não é muito diferente de uma struct em C 
Pode ser, o importante aqui não é em que método colocar, mas sim que a lógica de negócio de um determinado objeto esteja contida nele, mesmo que através de delegação. Delegacao, alias, faz com que a gente ganhe o melhor dos dois mundos. É possivel, por exemplo, usar o Command Pattern, aliado a Decorators, e se divertir bastante:
[code]public class Cliente … {
public void addPedido(Pedido p) {
new CommandExecutor(new AddPedido(this, p)).execute();
}
}[/code]
[code]public class AddPedido … {
public AddPedido(Cliente c, Pedido p) {
this.cliente = c;
this.pedido = p;
}
public void execute() {
// …
// checa todas as regras, joga excecoes, etc
// …
c.getPedidos().add(p);
p.setCliente(c);
}
}[/code]
Dentro do CommandExecuter, voce pode se divertir decorando o command com transacoes, configuracoes extras, etc e tal. Mas quem tá de fora, ou seja, sua interface, não fica nem sabendo sobre o que está debaixo dos panos. O importante aqui é isolar os problemas. Persistência, distribuição e esse tipo de coisa podem ser isolados dentro do seu modelo de objetos, sem que a interface fique se preocupando muito com isso. O que tem de tão horrível em chamar um monte de setXXX() e addXXX() em um objeto de negocio, e quando terminar de trabalhar chamar um save()? 
Agora, quanto aos “contras” de se ter um modelo de objetos rico:
Nao necessariamente. Como eu expliquei acima, os objetos do seu dominio so precisam servir de fachada pra um monte de outras esquisitices por baixo. E, dessas esquisitices, ninguem mais precisa ficar sabendo alem dos seus objetos de negocio
A quantidade de codigo nao aumenta o custo de transporte. A quantidade de dados, sim. Lembre-se que a serializacao não transporta o codigo toda vez que vc serializa um objeto, mas só o estado daquele objeto.
Não senhor, e alias muito pelo contrario. Eh possivel fazer TableModels mais inteligentes quando vc trabalha com objetos mais “completos”. Uma JTable que representa os Itens de um Pedido pode ser um Observer do Pedido, e adicionar um novo item ao pedido modifica a JTable, e nao o contrario (modificar a JTable causa uma alteracao no Pedido). Mais facil, mais OO, e com certeza usando menos codigo
