[quote=sergiotaborda]
Mas lá não tem nenhum código. Eu pedi exemplos de código que vcs já tenham usado nesta situação. Mas como já entendi que vcs não tem esses exemplos nem vou mais perguntar nada.
Eu acho claro que usar Domain Model pode ser compativel com TO embora os TO violem explicitamente o segundo texto que citei. Duplicando até os dados do dominio que podem ser complexos. É possivel ? sim. É Anemico ? Sim! é este o ponto que eu gostaria de discutir e não o que eu li ou deixei de ler, que idade eu tenho ou se sei inglês. OK !?[/quote]
Não é paternalismo, mesmo porque seu significado não cabe, é simplesmente o fato que as respostas estão no texto de maneira clara e você parece que não lê.
Em um sistema distribuido você tem os Assemblers convertendo entre Domain Objects e os DTOs, fora essa conversão, teu modelo continua rico, pois todo comportamento não escapou do lugar que deveriam ficar.
Quanto ao que constitui aquilo que o Martin Fowler chama de Anemic Domain Model, como você mesmo colocou, é uma quimera, um engodo, é ter objetos que parecem/deveriam possuir comportamento rico, porém não passam de simples struts.
Seguindo essa linha, chamar um sistema que usa de DTO de anêmico não tem sentido, afinal, os objetos utilizados para transporte de rede fazem exatamente aquilo que se propoem e parecem. Ninguém vai confundir um DTO com um DO, no caso de ambos existir.
DTOs são um artifício para otimizar o transporte pela rede. Falar que eles invalidam o uso de domain modeling é tão sem nexo quanto dizer que por precisar converter de String para int o conteúdo de um textfield quando transfere o valor da GUI para o domain model, o sistema é anêmico.
Um sistema não existe somente com o domain model, existem muitas outras partes que não necessáriamente possuem um domínio, tão pouco precisem. O fato de ser anêmico, como o Fowler fala, a grosso modo, diz mais a respeito a programadores que escrevem código lixão achando que estão usando DDD e abafando.
Você quer código? Bom está ai seu código de como suar DDD com DTOs:
class ConsultaPorNomePessoaDTO {
String nome;
}
class Pessoa {
String nome;
String sobrenome;
public boolean possuiParentesco(Pessoa outra) { return sobrenome.equals(outra.sobrenome); }
}
class PessoaAssembler {
public ConsultaPorNomePessoaDTO conv(Pessoa p) {
ConsultaPorNomePessoaDTO dto = new ConsultaPorNomePessoaDTO();
dto.nome = p.nome + " " + p.sobrenome;
return dto;
}
public Pessoa conv(ConsultaPorNomePessoaDTO p) {
return PessoaRepository.recuperaPorNomeCompleto(p.nome);
}
}
interface SistemaXptoFacade {
List<ConsultaPorNomePessoaDTO> buscaParentes(String nomeCompleto();
}
Veja nesse exemplo que: o DO possui comportamento; o DTO é usado apenas para transferencia de dados pela rede; e o Assembler é utilizado para conversão.
