BT

Migrando do Desenvolvimento Guiado por Dados para o Desenvolvimento Guiado por Domínio

por Jan Stenberg , traduzido por Robison Tesini em 12 Nov 2013 |

Intrigada e inspirada pelo Domain-Driven Design (Desenvolvimento Guiado por Domínio), ou DDD, mas com uma grande experiência em Data-Driven Development (Desenvolvimento Guiado por Dados), Julie Lerman lutou, discutiu e lamentou até que conseguiu utilizar suas habilidades com DDD. Lerman, que é uma MVP da Microsoft desde 2003 e trabalha como consultora e mentora na plataforma .NET, supõe que vários desenvolvedores passam pela mesma luta. Este é o motivo dela compartilhar as lições aprendidas em três artigos na revista MSDN.

Lerman enfatiza que DDD serve para comportamentos mais complexos, algo que não existe em algumas partes de uma aplicação. Para módulos de uma aplicação que fazem uma simples criação, leitura, alteração e deleção de um determinado objeto no banco, ou seja CRUD (create/read/update/delete), pode-se escolher uma abordagem que não seja DDD. Porém, para módulos que possuam um comportamento mais complexo além de um CRUD, a sugestão da Lerman é que se identifique as partes complexas e separe-as aplicando DDD somente nestas partes do software.

Ao pensar em DDD para modelar o domínio de uma aplicação, Lerman foca no negócio, trabalhando com as tarefas e comportamentos necessários. Segundo Lerman, a persistência de dados não está relacionada com os problemas das regras de negócio do software, sendo assim, não interfere tanto no projeto do domínio.

O compartilhamento de tipos de dados em diferentes sub-sistemas é algo que Lerman não concorda. Ela sempre achou que compartilhar tipos era obrigatório, inclusive trabalhando com a mesma tabela no mesmo banco de dados. DDD mostrou para ela que é perfeitamente aceitável NÃO compartilhar um modelo de domínio, sendo assim, pode-se armazenar o mesmo tipo de dado de diferentes sub-sistemas em tabelas diferentes de bancos diferentes. Ou seja, duplicar dados não é um crime; inclusive com o passar do tempo pode simplificar seu sistema ao remover a necessidade de compartilhar dados.

Em suas reflexões finais nos artigos, Lerman examina alguns problemas que ocorrem ao utilizar ferramentas de ORM, no caso dela o Entity Framework. Um problema é o de relacionamentos uni-direcionais, que é a maneira predileta de relacionamento entre entidades quando se trabalha com DDD. Eric Evans, o autor de livro original de DDD, aconselha que "é importante para restringir os relacionamentos, o tanto quanto possível", porém a forma de relacionamento que Lerman tem usado desde que começou a trabalhar com Entity Framework foi o bi-direcional. Agora ela acha que, embora sejam convenientes, os relacionamentos bi-direcionais raramente são necessários para o domínio e remover este tipo de relação pode diminuir algumas complexidades de manutenção de relacionamentos de entidades.

Os artigos da Lerman são acompanhados de um exemplo escrito em C# e também utiliza o Entity Framework, a ferramente da ORM da plataforma .NET da Microsoft.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Link para os artigos by Vinicius Serpa

Poderia haver um link para os artigos mencionados nesta notícia...

Concordo by Edson Parizoti Junior

Em relação a duplicação de dados, concordo que não é um crime, mas é preciso muito critério. Referente a recomendação de 'escolher estratégia diferente do DDD para modulos menos complexos' me fez lembrar este outro interessante artigo 'O mapeamento entre dados relacionais e objetos (ou: “OO or not OO? That is the question”)' <msdn.microsoft.com/pt-br/library/cc580623.aspx> e vai bem de encontro com os padrões Roteiro de Transação, Módulo Tabela e Modelo de Momínio explicado por Martin Fowler no excelente livro 'Padrões de Arquitetura de Aplicações Corporativas'.

Re: Link para os artigos by Rafael Sakurai

Obrigado pelo comentário Vinicius.

A notícia foi atualizada com os links para os artigos mencionados.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT