Tip:
Highlight text to annotate it
X
Saudações,
Neste vídeo iremos conhecer um pouco sobre o que é o design dirigido ao domínio, ou
DDD. Esta apresentação é o resultado do trabalho
realizado para a matéria de arquitetura de software
Ministrada pelo professor Eduardo Manuel de Freitas Jorge, no curso de Engenharia de Software
Da Universidade Salvador Unifacs. E desenvolvido pela equipe formado por Daniel
Cordeiro, Frederico Lima, e Saulo Mendonça.
Para melhor entendimento, vamos começar pela organização desta apresentação, onde iniciaremos
falando dos objetivos do trabalho, então realizando uma breve introdução, seguida
da história e de alguns fundamentos básicos do DDD, o que inclui os conceitos de linguagem
ubíqua e do design dirigido por modelo. Este último será explorado quando falarmos da
arquitetura em camadas, e alguns dos padrões para expressar o modelo, e a utilização
de módulos. O que nós trará para a conclusão da apresentação.
Dando andamento a nossa apresentação, que tem como objetivo de realizar o introdução
sobre o que é o design dirigido ao domínio, e faremos isso ao apresentar suas principais
práticas e padrões utilizados, que possam permitir nosso entendimento do assunto.
Mas enfim, o que é DDD? Antes de responder isso, vamos analisar uma
outra pergunta. Porque desenvolvemos software? Normalmente temos dois objetivos ao criar
um software. Para automatizar um processo que exista no mundo real, ou para resolver
um problema de negócio que também exista no mundo real. E é este processo e problema
que queremos resolver, neste universo da engenharia de software, é o que associamos como o Domínio
do software
Ou seja, podemos dizer que quando estamos desenvolvendo um software, estamos lidando
com o seu domínio. Podemos também dizer que todo problema possui uma dificuldade,
uma complexidade. O que normalmente é associada ao objetivo central do software. Com isso
podemos fazer mais uma associação, podemos dizer então que a complexidade do software
está ligada com o seu domínio.
E é nessa associação que está a base do DDD. Se queremos construir um software, precisamos
primeiramente entender o que estamos criando. Para entender como um software será criado,
precisamos entender do seu domínio.
E foi a partir desta ideia que Eric Evans publicou em dois mil e três o livro Domain
Driven Design, Atacando as complexidades no coração do software, o que deu origem ao
termo DDD. O livro é composto de um conjunto de padrões e boas práticas que podem auxiliar
no desenvolvimento de um software com foco no seu domínio. O objetivo do livro não
era de trazer conceitos novos, mas de sistematizar aquilo que vinha sendo trabalhado a mais de
duas décadas, pois o DDD não é uma metodologia ou tecnologia nova, o seu objetivo é orientar
o leitor de como pensar e agir para desenvolver um software de qualidade.
E com isso temos o principal ponto do DDD, de que o domínio é o coração do software,
ou seja, para desenvolver um software devemos primeiramente entender o domínio. Mas então
temos a pergunta. Como entender o domínio? Vamos analisar um exemplo.
Digamos que estamos construindo um sistema complexo para um banco.
Seguindo a lógica que estabelecemos, devemos entender do domínio do software. Neste caso
devemos entender de como um banco funciona. Então pergunto, quem entende de banco? O
desenvolvedor? O Arquiteto? Ou o analista? Normalmente nenhum deles vai saber de tudo
aquilo necessário para entender de como um banco funciona. Para isso devemos contar com
alguém que entende de como um banco funciona. Ou seja, alguém que entenda do processo realizado
dentro de um banco. Em outras palavras estamos falando de alguém que entenda do domínio.
Com isso temos um dos primeiros pontos do DDD, para desenvolver um software devemos
trabalhar com um especialista do domínio.
Com esta ideia em mentes, teremos um meio de entender o domínio, agora podemos construir
o software. Mas como fazer isso? Afinal sabemos que software é código, e domínio é basicamente
informação, é conhecimento, distribuída em diversas formas. Como fazer essa transição?
> Para isso devemos transformar aquilo que sabemos
do domínio em algo que possa ser transferido para código. Ou seja, criar uma abstração
do domínio, uma representação. No nosso caso, essa abstração é chamada de modelo.
Um modelo pode ter diferentes formatos, sejam textos, diagramas, ou desenhos. O que importa
é que este modelo será a base de todo o desenvolvimento, o que o desenvolvedor, o
arquiteto, o analista ou o especialista do domínio vão utilizar para se comunicar.
Falando em se comunicar, vamos analisar o nosso próximo tópico, que trata exatamente
do problema que pode ser a comunicação. Afinal sabemos que da mesma forma que um desenvolvedor,
por exemplo, não sabe de tudo do domínio, ele também não deve saber de todos os termos
e jargões que o especialista do domínio sabe e utiliza. O inverso também e verdadeiro.
São universos diferentes com linguagens diferentes. E linguagem diferentes impacta na capacidade
de comunicação.
Para resolver este problema, a orientação é de utilizar uma linguagem em comum entra
as duas partes. Que é o que chamamos de linguagem ubíqua, ou onipresente. Que será a linguagem
à ser usada no modelo para que todos as partes possam utilizar e entender o que cada uma
está querendo dizer.
Com isso temos o essencial para construir a nossa representação do domínio,o modelo.Agora
veremos como transformar o modelo em código.
Esse procedimento é bastante utilizado, porem de uma forma não muito eficaz. Analisando
as metodologias convencionais, temos a criação do modelo em duas etapas. Primeiro criamos
o modelo de análise,e este pronto, criamos então o design do software, o qual será
utilizado para realizar a codificação. Lembrando que normalmente estes processos são realizado
por pessoas diferentes. É um procedimento que funciona, mas traz um grande problema,
Como a pessoa que faz o modelo de análise é diferente de quem faz o design, pode ocorrer
a perca de informação nesta transição. Pois a forma como um processo foi compreendido
na realização da análise pode não ser a mesma que no design. E como queremos focar
em entender o domínio, não podemos perder informação. Como proceder então? A resposta
proposta é na criação de um modelo único, que junte a análise e o design em um único
modelo. Este é o nosso modelo de domínio.
O que é fácil dizer, mas pode se tornar muito difícil de executar. Sistemas muito
complexos podem resultar em modelos muito complexos e difíceis de realizar. Para isso
o DDD sugere um conjunto de padrões que possam ser utilizados para auxiliar na criação
do modelo. Iremos falar de alguns destes padrões, que são utilizados para isolar o domínio,
e para expressar o modelo.
O primeiro passo proposto é de isolar o domínio e dividir em camadas. Mas porque isolar o
domínio? Você pode estar perguntando. Bom, como vimos, a complexidade do software está
no seu domínio e que é a parte maios importante do software. Porém o que ocorre que apesar
de sua importância, normalmente representa apenas uma pequena parte do código final,
pois além das regras de negócio que representam o domínio, temos outros elementos, como a
interface, os bancos de dados, a comunicação com outros sistemas, entre outros. Então
ao dividirmos as camadas e isolarmos o domínio, nós podemos limitar a complexidade do software
a apenas uma pequena parte, diminuindo desta forma a complexidade dos demais elementos,
e com isso diminuindo o acoplamento entre as partes. O que é bastante importante pois
o domínio pode sofrer alterações constantemente.
Com isso temos nossa divisão em quatro camadas. A camadas de Interface, que irá realizar
a interação com usuários e demais sistemas, A camada de Aplicação, que irá coordenar
as atividades do sistema. A camada de Domínio, que contém as regras de negócio,e a camada
de infraestrutura, que dá suporte para as demais camadas e realiza persistência de
dados.
Dando continuidade, o nosso próximo passo é de expressar o modelo. E podemos realizar
isso utilizando estes três padrões principais: Serviços, entidades, e objetos de valor.
Para isso é utilizados o princípio de objetos da programação orientada a objetos. Onde
teremos os diferentes elementos do nosso domínio separados inicialmente como objetos, e a partir
destes, podemos classificá-los nestes três tipos: Entidades, serão aqueles objetos que
possuem uma identidade própria, que não são dependentes de seus atributos. Ao contrario
temos os objetos cuja essência está no seu atributo, e que não possui identidade. Para
estes damos o nome de objetos de valor. Mas também ocorre o caso de um objeto não ser
nem uma entidade ou um objeto de valor. São aqueles que representam um ação, que realizam
uma atividade. Estes são os serviços.
Com isso podemos dar inicio a criação do modelo do domínio. Mas como já mencionamos,
o modelo pode se tornar muito complexo devido ao seu tamanho, o que pode dificultar sua
leitura e entendimento.
Para isso a orientação que o DDD dá é de dividir o modelo em módulos. Assim como
um software pode ser codificado em partes, ou módulos, assim pode ser feito o modelo.
Porem alguns cuidados devem ser tomadas sobre como dividir os módulos, sempre buscando
manter uma alta coesão e um baixo acoplamento entre eles.
Com isso chegamos ao fim de nossa apresentação. E com isso esperamos que nosso objetivo principal
tenha sido alcançado, de que você tenha entendido o que é o DDD, e o porquê utiliza-lo.
Só lembrando que o apresentado aqui foi apenas uma parte de tudo aquilo que é encontrado
no livro de Eric Evans, que é a base do DDD. Logo, para quem quiser se aprofundar no assunto,
recomendamos sua leitura. Podemos recomendar também o livro sobre DDD publicado online
e gratuitamente pela InfoQ, que traz uma síntese do livro de Evans.
Enfim, agradecemos a atenção. Até mais.