BT

Potencializando o Domain-Driven Design em aplicativos utilizando Entity Framework

por Jan Stenberg , traduzido por Paulo Vitor Rendeiro em 12 Jun 2014 |

O Domain-Driven Design (DDD) trata, fundamentalmente, do domínio da aplicação, e não de sua persistência, explica Julie Lerman em uma recente apresentação na conferência Øredev, organizada na Suécia.

A Julie, MVP da Microsoft desde 2003, atualmente trabalhando como consultora na plataforma .NET, dedicou 25 anos de sua carreira em programação em banco de dados e, anos depois, utilizou o Entity Framework (EF), porém, agora, está inspirada pelo DDD, foca no domínio da aplicação.

Com base em seu experiência com DDD, ela conta que muitas pessoas que trabalham utilizando os conceitos de DDD e ignoram a persistência; o banco de dados se torna um adendo ao final do desenvolvimento. Mas ainda assim, a longo prazo, se tem que armazenar as informações no banco de dados e, mesmo que Julie se concentre no domínio, ela desde o começo quer ter a certeza de que o mecanismo de persistência, quando adicionado, vai funcionar.

O contexto delimitado é, na visão de Julie, o conceito mais importante do DDD. Ao invés de pensar sobre tudo em uma aplicação, ao mesmo tempo, entidades, comportamentos, etc., o contexto delimitado a ajuda a pensar sobre o problema de uma maneira mais estruturada, em subsistemas. Quando trabalha com atendimento a clientes, ela pode ignorar as interações com outros subsistemas como, por exemplo, o de marketing. Pode haver a necessidade por uma identidade ou uma pequena parte de informação a partir de um outro contexto, mas para a maior parte, as informações são delimitadas dentro de um contexto de domínio.

No caso de estar trabalhando com a mesma entidade, como por exemplo cliente, em contextos diferentes, ela redefine a entidade cliente em cada contexto, embora todas sejam persitidas na mesma tabela Cliente. Uma extensão em potencial, para Julie, é a completa separação de contextos através do uso de tabelas diferentes, ou mesmo bancos diferentes.

O Value Object ou, simplesmente, o padrão VO, tem sido um conceito confuso para Julie. Ela já escutou cinco explicações diferentes de especialistas em DDD, cada um com seu ponto de vista, porém, todos corretos, o que a ajudou a enriquecer sua visão. Agora, para Julie, um VO é um objeto imutável sem uma identidade que funciona como um tipo complexo que é persistido em diversas colunas no banco de dados.

Normalmente, Julie utiliza um modelo de domínio também como um modelo de dados, porém, em alguns domínios muito complexos ela encontrou a necessidade de separar o modelo de persistência. Pode-se observar este cenário, por exemplo, quando é preciso trabalhar com bancos de dados legados.

Mais cedo, em 2013, Julie escreveu três artigos sobre lições aprendidas na transição do modelo de desenvolvimento Data-Driven Development para o Domain-Driven Design.

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 mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

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-2014 C4Media Inc.
Política de privacidade
BT