DDD ASP.NET: Criando um reposit�rio de dados

Artigo no estilo: Curso

Fique por dentro

Neste artigo abordaremos o desenvolvimento de uma aplicaç�o ASP.NET com a utilizaç�o de um padr�o de desenvolvimento conhecido como DDD (Domain-Driven Design), que tem por finalidade orientar o desenvolvimento de projetos com base no dom�nio de nossa aplicaç�o e n�o nas tecnologias que ser�o utilizadas para o seu desenvolvimento.

Os principais fatores para a utilizaç�o do DDD s�o a independ�ncia de tecnologias e o alinhamento do c�digo com o neg�cio. Devido a essas raz�es, � de grande import�ncia a utilizaç�o do DDD.

Apresentaremos ent�o a criaç�o de uma estrutura b�sica para um webservice, apresentando os principais conceitos de utilizaç�o do DDD e sua estrutura, onde tamb�m usaremos o Entity Framework.

O desenvolvimento de softwares com base na arquitetura em camadas tem sido a norma vigente em projetos corporativos por algum tempo. Desenvolvemos nossas soluç�es em grupos de responsabilidades como interface do usu�rio, serviços, acesso a dados, infraestrutura, entre outros.

Podemos ligar essas camadas definindo as refer�ncias a elas a partir da camada de serviços. Existem v�rias maneiras de definir essas camadas e suas refer�ncias. As escolhas que fazemos aqui dependem do tipo de projeto que ser� utilizado, podendo este ser Web, WPF, WCF, games, etc.

� certo que para o desenvolvimento de um software s�o necess�rias habilidades e conhecimentos da equipe t�cnica respons�vel pela sua criaç�o, mas al�m desse ponto, e sendo inclusive mais importante, � necess�rio ter o conhecimento com relaç�o ao prop�sito do software, o que quer dizer que precisamos ter o conhecimento do dom�nio da aplicaç�o.

Este, por sua vez, � obtido atrav�s de pessoas especializadas no ramo do neg�cio para o qual o software ser� desenvolvido. Esta pessoa tem que estar em trabalho conjunto com a equipe de desenvolvimento para que se tenha a real dimens�o do projeto, de seus recursos e das necessidades da empresa.

� aqui onde entra o nosso tema de estudos, o desenvolvimento de aplicaç�es com base no seu dom�nio, ou mais popularizado como DDD � Domain-Driven Design.

O DDD � um conjunto de princ�pios e padr�es que ajudam os desenvolvedores a manterem a eleg�ncia no desenvolvimento dos objetos em seus sistemas. Sendo aplicado de forma correta, ele poder� levar a abstraç�es de software chamados modelos de dom�nio, que s�o respons�veis por encapsular a l�gica de neg�cio da aplicaç�o. Neste artigo falaremos ent�o sobre os conceitos b�sicos e tamb�m sobre os padr�es de projetos pertinentes para o DDD.

Ele � uma abordagem de desenvolvimento que abrange tr�s pontos principais, que s�o a abordagem para o desenvolvimento do software em conjunto, a abordagem sobre as iniciativas estrat�gicas do neg�cio, e por fim, atender �s exig�ncias t�cnicas reais do software.

� Abordagem para o desenvolvimento do software � este ponto � respons�vel pela integraç�o entre a equipe de desenvolvimento e as pessoas que conhecem o dom�nio do sistema;

� Iniciativas estrat�gicas � este princ�pio ajuda a definir as melhores relaç�es interorganizacionais da equipe, fornecendo formas de reconhecimento de poss�veis falhas no projeto.

� Atendimento das necessidades do software � nesta etapa � onde s�o atendidas as exig�ncias t�cnicas reais do software, utilizando ferramentas de modelagem para analisar e desenvolver as entregas de software execut�veis. Estas ferramentas permitem que os desenvolvedores produzam softwares com uma codificaç�o correta do modelo mental dos especialistas de dom�nio, o que resulta em uma menor margem de erros de interpretaç�o

Quando começamos a pensar sobre as quest�es referentes �s tecnologias, estas de certa forma, tornam-se detalhes de implementaç�o, onde o tipo de implementaç�o exato pode variar. N�s realmente n�o nos importamos com qual pacote gr�fico ser� utilizado, isso � um detalhe de implementaç�o.

N�s n�o nos importamos mais com que tecnologia ORM (BOX 1) usamos; isso � um detalhe de implementaç�o. Claro que as preocupaç�es relacionadas com a tecnologia ser�o aspectos importantes da fase de planejamento, mas n�o t�o importantes como a forma de representar corretamente o nosso neg�cio no c�digo.

BOX 1. ORM

� uma t�cnica de programaç�o para convers�o e mapeamento de dados entre bancos de dados relacionais e linguagens de programaç�o orientadas a objetos. Elas criam um objeto virtual que representa o banco de dados que poder� ser usado a partir de uma linguagem de programaç�o de forma transparente para o usu�rio.

Em uma abordagem orientada a tecnologia � dada uma prioridade maior � tecnologia do que ao dom�nio, onde reca�mos a quest�es como: "Temos de mudar o dom�nio do cliente, pois sua estrutura n�o se encaixa com a utilizaç�o do LINQ to SQL".

No DDD, a direç�o � invertida: "Uma parte importante da nossa estrutura de dom�nio do cliente mudou, por isso precisamos atualizar nossas classes LINQ to SQL em conformidade.". Uma mudança na tecnologia nunca deve forçar uma mudança em seu dom�nio, pois ele � uma entidade independente que s� muda se mudarem suas regras de neg�cio ou quando descobrimos que nossa l�gica de dom�nio foge do escopo do nosso neg�cio.

Tenha em mente que n�o � o n�mero de camadas que torna a nossa soluç�o "moderna". Se aplicarmos corretamente o uso do DDD, ent�o teremos um aplicativo f�cil de se trabalhar e aberto a todos os tipos de extens�es, mesmo as n�o pervistas. Este �ltimo aspecto � importante manter em mente, pois hoje em dia as expectativas e lista de desejos dos clientes mudam com muita frequ�ncia.

Por conta disso, temos praticamente uma atualizaç�o do produto quase toda semana, onde trabalhamos em estreita colaboraç�o com o cliente em cada incremento que constru�mos. Com base nestes produtos incrementais o cliente pode vir com novas exig�ncias e � melhor estarmos preparados para reagir rapidamente.

Nosso prop�sito aqui ser� criarmos uma aplicaç�o gen�rica de webservice, apresentando os principais conceitos de utilizaç�o do DDD e sua estrutura. Ao final deste curso teremos uma aplicaç�o base com as seguintes camadas:

� Infraestrutura: oferece serviços de recursos t�cnicos para acomodar preocupaç�es transversais, como persist�ncia de dados.

� Acesso a dados (reposit�rio): camada de acesso a dados e tecnologia de persist�ncia, como Entity Framework.

� Dom�nio da aplicaç�o: esta ser� a camada respons�vel pelas nossas entidades empresariais e l�gica (nosso foco).

� Serviços de aplicativos: � respons�vel por coordenar as tarefas e delegar trabalho para objetos de dom�nio. Esta camada n�o cont�m l�gica de neg�cio.

� Web: o consumidor final da aplicaç�o, cujo �nico objetivo � apresentar os dados e receber as requisiç�es do usu�rio. A implementaç�o dessa camada utilizar� a tecnologia WebAPI para que n�o precisemos perder tempo com estruturaç�o de CSS e HTML.

O DDD define uma s�rie de "blocos" de padr�o (Building Blocks) que s�o utilizados para projetar um dom�nio. Esses blocos de construç�o fazem parte de um conceito de linguagens de padr�es, os quais descrevem as responsabilidades dos objetos de dom�nio. Cada um desses blocos tem sua import�ncia, a qual iremos descrever no decorrer do artigo.

Entidades e objetos de valor (Entities e Value Objects)

Os objetos de dom�nio podem ser divididos em entidades e objetos de valor. Uma entidade � um objeto com uma identificaç�o �nica. Esta identificaç�o �nica � a propriedade mais importante de uma entidade, � ela que ajuda a distinguir entre dois objetos id�nticos.

Podemos ter duas pessoas com o mesmo nome, mas se os seus IDs s�o diferentes, ent�o estamos falando de duas pessoas diferentes. Um ID � normalmente um inteiro ou algum outro valor de sequ�ncia gerado aleatoriamente com base em algumas propriedades do objeto.

Uma vez que a entidade tenha sido persistida, o seu ID nunca deve mudar, caso contr�rio podemos perder o controle da mesma.

Por outro lado, um objeto de valor n�o tem qualquer tipo de identificaç�o. A principal caracter�stica que define um objeto de valor � que ele n�o tem uma identidade. Ele tem por intuito representar algo apenas pela definiç�o de seus atributos.

Dois objetos de valor podem ter atributos id�nticos, desta forma, sendo eles id�nticos. Um outro aspecto comum aos objetos de valor � que eles devem ser imut�veis, onde uma vez que criados, eles n�o podem ser alterados.

�s vezes n�o � f�cil decidir se um objeto espec�fico � uma entidade ou um objeto de valor. Se dois objetos t�m propriedades id�nticas, mas ainda assim precisamos fazer a distinç�o entre eles, ent�o � mais prov�vel que cada um seja uma entidade com uma identificaç�o �nica.

No caso em que dois objetos tenham propriedades id�nticas e n�s n�o nos importaremos com qual � qual, ent�o teremos dois objetos de valor. Se o mesmo objeto pode ser partilhado, por exemplo, o mesmo nome pode ser conectado a v�rios objetos individuais, provavelmente ir� se tratar de um objeto de valor.

Agregados e ra�zes agregadas (Aggregate e Aggregate Root)

A representaç�o de uma coleç�o de objetos que s�o ligados por uma entidade raiz (root aggregate). Os agregados (aggregates) s�o as principais unidades de trabalho presentes no DDD. Eles encapsulam suas implementaç�es, a fim de garantir a consist�ncia das mudanças ocorridas.

Os objetos raramente s�o �independentes�, eles possuem outros objetos ligados a eles ou mesmo fazem parte de um objeto maior. Um objeto do tipo Pessoa pode ter um objeto de Endereço, que por sua vez pode ter outra Pessoa associada a ele, caso mais de uma pessoa esteja registrada l�.

H� claramente uma necessidade de organizarmos os objetos de dom�nio em grupos l�gicos, que s�o os chamados agregados. Um agregado � um grupo de objetos associados que s�o tratados como sendo uma unidade com o prop�sito de alteraç�o de dados. Cada agregado tem uma raiz e seus limites claramente definidos.

A raiz � o �nico membro de um agregado ao qual os objetos externos podem fazer refer�ncia.

Persistence Ignore

No dom�nio de um projeto, o seu principal objetivo � a criaç�o de um modelo de dom�nio. Com isso, � preciso identificar quais s�o os objetos que iremos precisar para realizar as funcionalidades desejadas em nossas aplicaç�es.

Precisamos identificar as relaç�es entre os diferentes objetos e como eles interagem entre si, al�m disso, precisamos descobrir se o objetivo de neg�cio dos nossos clientes se torna alcanç�vel atrav�s do nosso modelo de dom�nio.

Aqui n�o precisamos saber da exist�ncia de banco de dados, nem precisamos saber como e onde os dados do dom�nio ir�o persistir ou mesmo se estes dados precisam persistir enquanto fazemos o modelo do dom�nio.

Esta �ignor�ncia� com relaç�o ao meio de persist�ncia far� com que nossos modelos de dom�nio estejam livres de qualquer acoplamento com a camada de persist�ncia da aplicaç�o. Isto acabar� por separar as preocupaç�es da persist�ncia e do seu mecanismo de comunicaç�o do nosso modelo de dom�nio.

Com isso, a nossa aplicaç�o estar� livre de acoplamentos com qualquer forma de armazenamento de dados e da� ser� muito mais f�cil de test�-la. Mas de qualquer forma, em uma aplicaç�o real precisamos ter um banco de dados.

A quest�o aqui � que n�o ser� o modelo de dom�nio que ter� conhecimento sobre isso. A camada que ser� respons�vel por saber e gerenciar persist�ncias da nossa aplicaç�o ser� a camada de Reposit�rios." [...] continue lendo...

DDD ASP.NET: Criando um reposit�rio de dados - Parte 1

Nesse artigo teremos uma conceituação geral sobre o DDD. Além disso, começaremos a estruturar a nossa aplicação simples de webservice, utilizando o Visual Studio.

Artigos relacionados