DDD - Raiz de agregado e repositório

[Ricardo Roberto]

Estou em um projeto trabalhando com DDD, estou com algumas dúvidas, já li vários post, mas não sanaram minhas dúvidas, pode ser algo relativamente simples, mas que não consegui tomar a decisão de qual abordagem seguir. A dúvida vem quando chega nos famosos repositórios, onde trabalho com Entity Framework. Nos projetos que trabalhei anteriormente(não era DDD), ao necessitar realizar uma alteração, solicitava a alteração ao repositório do meu objeto principal. Exemplo, tenho minha duas entidades: Pessoa e ContatoEletronico, possuia um repositório para Pessoa, no método de update no meu repositório de pessoa, buscava todos os contatos eletrônicos da pessoa que esta sendo alterada, comparava com a coleção de contatos que esta na Pessoa alterada, para saber qual contato eletrônico necessito inserir, alterar ou deletar, ainda no meu repositório setava para cada objeto o que ele deveria fazer, informando ao EF o que deveria ser feito para cada objeto, exemplo: (contexto.Entry(itemContato).State = System.Data.EntityState.Deleted;, este comando esta encapsulado em um repositório genérico).

Pensando em um projeto em DDD hoje, o que eu faria(iniciando desde o camada de serviço de aplicação).

A Camada de serviço de aplicação possui um método de AtualizarPessoa(PessoaDTO pessoa), será convertido o objeto pessoa utilizando uma factory, faria minhas validações, após isto acionaria o meu repositório de Pessoa que seria minha raiz de agregado, e faria o mesmo processo que faria no repositório que expliquei acima. Mas daí que vem um problema, pra eu executar esta rotina no meu repositório (buscar o que deve ser inserido, excluído ou deletado e seta-lo para que o entity saiba o que fazer), eu deixaria uma abertura, se no repositório de pessoa, fosse instanciado um objeto ContasAReceber, e setá-lo para inserir, iria funcionar, mas fica errado relacionado ao DDD. Uma idéia foi, somente o raiz de agregado possuir um repositório(a raíz de agregado herda de uma interface IAggregate) e o repositório é tipado com esta interface, então quando salvo a pessoa, só acionaria o pessoaRepository.Save(), o problema é que para o ORM's, você precisa falar o que ele deve fazer ao alterar suas coleções, ao salvar pessoa, ele não sabe, se tem que excluir algum contato, alterar etc. Vocês já passaram por isso? tem alguma sugestão para me dar? Vocês concordam que a responsabilidade de setar quem vai ser inserido, alterado e excluído é do repositório, pois isto só interessaria ao ORM. Li vários artigos falando que devemos deixar explícito o que você qr que seja feito, setando a inclusão, alteração, exclusão de cada objeto na collection, mas não vejo uma forma de fazer isto e não deixar aberto para para que o repositório de pessoa por exemplo, faça manutenção em uma entidade que não faça parte da sua composição.

Agradeço desde já.

[Daniel Moreira Yokoyama]

Isso não é realmente relativo a DDD mas à estratégia de persistência. E tanto o EF quanto o nHibernate mantém o tracking do que realmente precisa ser inserido/alterado/excluído da árvore da agregação.

Então eu aconselharia sim, a ir por este caminho, primeiro por ser mais simples, segundo pq já funciona.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Stay Sharp!

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
---
Você está recebendo esta mensagem porque se inscreveu no grupo ".Net Architects" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para dotnetarchitec...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

[Ricardo]

Value Daniel, você tem razão é sobre estratégia de persistência, mas coloquei sobre o DDD, pois na estratégia que postei, criando o repositório e setando o que será feito, acabo dando abertura para a raiz de agregado Pessoa dar manutenção em uma entidade que não faz parte de sua composição, você acha que estou tendo uma preocupação exagerada relacionada a isso? 

[Gustavo Cruz]

Ricardo,

Repositório, AFAIK, é sempre por raiz de agregação, exatamente para manter a consistência do seu modelo. Não existe problema algum em seu repositório trabalhar com mais de uma entidade, desde que essa faça parte da mesma raiz de agregação.

 Não faz sentido você trabalhar um agregado fora da raiz dele, portanto, não faz sentido persisti-lo fora dela também. A ideia é simples. Mas como o nosso amigo aí em cima já disse, isso é estratégia de persistência.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[Daniel Moreira Yokoyama]

É como o Ricardo falou...

Só falta entender por que você acha que o objeto não faz parte da composição. Se ele existe independente da entidade, então é bem capaz de não haver uma agregação, e aí sim você precisa de uma estratégia.

Do contrário, se ele faz parte da agregação, é natural que o repositório da agregação se responsabilize pela persistência de tudo.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Stay Sharp!

[Ricardo]

Concordo com você Gustavo, "Não faz sentido você trabalhar um agregado fora da raiz dele, portanto, não faz sentido persisti-lo fora dela também", só houve questionamento na equipe sobre estar permitindo que o desenvolver cometa este tipo de erro.