Aluan Henrique Alves

Cabral
Experincia:
2 anos coordenador de
assistncia tcnica e
consultoria comercial.
7 anos em desenvolvimento
freelance em tecnologias web
1 ano em consultor GED
E agora estou como
Coordenador de Projetos Cloud
do Grupo Soitic

Falaremos sobre o
que?

DDD!

COMEANDO A DESENVOLVER UMA NOVA

APLICAO
O que ns tradicionalmente fazemos quando iniciamos
uma nova aplicao de negcio? Ns vemos/lemos as
especificaes e achamos as funcionalidades. Ns
quebramos e dividimos em pequenas tarefas. Na maioria
dos casos em conjunto com essa quebra tambm vem a
estimativa e o plano para a funcionalidade. Ns
modelamos o banco de dados algumas vezes
desenvolvido pelo lder do time ou pelos prprios
desenvolvedores. Ns comeamos a codificar.

COMEANDO A DESENVOLVER UMA NOVA

APLICAO

Ento??? O que tem de errado com essa

metodologia??? Ns estamos fazendo tudo certo??
No estamos?

COMEANDO A DESENVOLVER UMA NOVA

APLICAO

MANUTENO e EXTENSIBILIDADE dos nossos projetos! A

resposta SIM e NO! Sim pelo fato que estamos
entregando os nossos projetos. Mas NO! Ns no
estamos pensando na

COMEANDO A DESENVOLVER UMA NOVA

APLICAO
Pensando em projetos que j trabalhei e usando a metodologia
tradicional. Eu consegui algumas situaes, para quem da rea,
tente se identificar tambm:
1. Projetos com as mesmas funcionalidades implementadas do
mesmo jeito ou pouco diferente em lugares diferentes.
2. Temos mais de um objeto para o mesmo item.
3. Temos objetos quem contm propriedades que no so na
verdade atributos do objeto
4. Temos nenhum relacionamento e at um relacionamento pobre
entre itens
5. Olhando para os seus objetos somente no possvel entender
o que toda a aplicao faz.

COMEANDO A DESENVOLVER UMA NOVA

APLICAO
Ento, a abordagem tradicional - "Projetando a aplicao a
partir de banco de dados" um conceito pra se jogar fora? Na
verdade, no! Mas se voc tiver um aplicativo complexo para
se desenvolver, esta abordagem de design de baixo para cima
no dita que voc venha com um design orientado a objeto
adequado.
Qual a soluo ento?
A soluo DDD (Domain Driven Design).

O que DDD?

O que DDD?

Domain-Driven Design no uma tecnologia ou uma

metodologia. DDD fornece uma estrutura de prticas e
terminologia para a tomada de decises de design que
se concentram em acelerar projetos de software que
tratam de domnios complicados.

Conceitos que vamos

ver?

Conceitos que vamos ver

1. Compreendendo o Domnio.
2. Linguagem ubqua.
3. Contexts and Bounded Contexts.
4. Entities and Value Objects.
5. Aggregates and Aggregate Roots.
6. Persistence Ignorance.
7. Repository.
8. Domain Service.

Compreendendo o
domnio

Compreendendo o domnio

Domnio pode ser definido como uma esfera de conhecimento,

influncia ou atividade.
A rea onde o usurio aplica o
programa o domnio do software.
Comeou a ver o que de domnio a partir desta definio?
Voc pode dizer o que o domnio do projeto que voc est
trabalhando neste momento? Voc pode dizer o que o domnio
do famoso site YouTube?

Compreendendo o domnio
Vamos dizer que voc est contratado para projetar um Edifcio. O
requisito :
Voc tem uma quantidade definida de terra. Seu edifcio ter 6
andares. Cada andar ter 4 apartamentos.
Qual o seu domnio aqui?
O domnio o Edifcio(?). Poderia ser. Mas observe que, se voc
considerar Edifcio como seu domnio voc pode perder alguns
detalhes granulares para sua exigncia. O edifcio que voc est indo
para a concepo deve ter o projeto para apartamentos onde as
pessoas iro viver.

Compreendendo o domnio
Assim, um termo geral "Edifcio" pode fazer-nos perder alguns
detalhes. Assim, podemos diminuir o nosso domnio para "Edifcio
Residencial".
Agora, quando voc fala sobre o seu trabalho com os engenheiros e
tambm com as pessoas que voc engajados para projetar o edifcio,
o termo " Edifcio Residencial" mais significativo para todos os
envolvidos. Percebeu a pequena mudana na linguagem aqui? O
empreiteiro est dizendo a voc para projetar um edifcio onde
haver 4 apartamentos em cada um dos 6 andares. Agora, se voc
enviar um engenheiro ao local dizendo que vamos precisar para
construir um edifcio l, eles podem no considerar vrios atributos
que um edifcio residencial deve ter. Por outro lado, se voc usar o
termo " Edifcio Residencial", o mais provvel que ele vir com uma
anlise vlida.
Assim chegamos a uma "linguagem ubqua".

Linguagem ubqua

Linguagem Ubqua

O conceito simples, que os desenvolvedores e os negcios

devem compartilhar uma linguagem comum que ambos
entendem a dizer as mesmas coisas, e mais importante, que
definido na terminologia de negcios, no terminologia
tcnica.

Linguagem Ubqua: Exemplos

EXEMPLO 1:
Errado:
A proporo entre comprimento e largura dos menores
cmodos so de 6:4.
Correto:
Comprimento do quarto das crianas ser de 6 metros
e largura ser de 4 metros.

Linguagem Ubqua: Exemplos

Note-se que, para o proprietrio do edifcio "menores

cmodos", "proporo" - todas essas coisas poderiam ser
termos tcnicos. Pelo contrrio, mais fcil para ele
entender o quarto das crianas, quarto de hspedes, sala
de estar, etc. E medio explcita mais significativo para
ele.

Linguagem Ubqua: Exemplos

EXEMPLO 2:
Vamos ver um exemplo do ponto de vista de software.
Errado:
Em funcionalidade de pesquisa, vamos considerar caracterstica
flexional e thesaurus do servidor SQL para fazer a pesquisa mais
relevantes. Alm disso, tambm ir excluir as palavras vazias a
partir da busca para torn-la mais precisa.
Note-se que, o seu especialista de domnio no pode ser uma
pessoa tcnica e, portanto, ele no pode entender o que voc quis
dizer com as palavras "flexional", "Thesaurus", " palavras vazias"
etc.

Linguagem Ubqua: Exemplos

Correto:
Na funcionalidade de pesquisa, vamos considerar todos os
sinnimos da frase de pesquisa para que ele no exclui
resultados relevantes. Alm disso no vamos diferenciar
nenhuma palavra de busca por seu nmero (singular ou
plural), conjugao, particpio, etc; para que o resultado
torna-se mais preciso. Alm disso, como esperado em
qualquer pesquisa, vamos ignorar todas as palavras
irrelevantes que no tm qualquer valor na pesquisa.
palavras
ser "mas",
"sobre",
Voc
v irrelevantes
a diferena poderiam
de linguagem
aqui? "onde",
Realmente
um
etc.
idioma
correto pode fazer todas as partes envolvidas pensar
e compreender da mesma maneira.

Linguagem Ubqua
Vamos voltar ao nosso domnio "Edifcio Residencial". Olha, voc
pode prosseguir com o projeto de construo residencial como uma
nica tarefa e resolver a coisa toda em conjunto. Mas ser realmente
maneira sensata a fazer? Note que, se voc considerar apenas este
uma nica unidade de trabalho, voc pode perder muitas coisas.
Projetando um edifcio est relacionada com tantas coisas. Por
exemplo:
voc
precisa
considerar
ventilao,
utilidade,
estacionamento, espao da comunidade etc.
Agora voc v, diferentes contextos outros esto chegando. Esta a
forma como o conceito de "Context" e "Bounded Context" que surge
em Domain Driven Design.

Context e Bound
Contexts

Context e Bound Contexts

Bound Contexts pode ser considerada como um mini

aplicativo, contendo o prprio domnio, mecanismos prprios de
cdigo e de persistncia. Dentro de um Bound Contexts, deve
haver consistncia lgica; Cada Bound Contexts deve ser
independente de qualquer outro Bound Contexts.

Context e Bound Contexts: Exemplos

Pense em um sistema de e-Commerce. Inicialmente voc pode

dizer que uma aplicao de mbito comercial. Mas se voc
olhar mais de perto, voc vai ver que existem outros contexts
tambm. Como: Inventrio, Entrega, contas etc.

Context e Bound Contexts

Dividir uma grande aplicao entre os diferentes Bound
Contexts corretamente ir permitir que voc faa a sua
aplicao mais modular, ir ajud-lo a separar diferentes
preocupaes e far com que o aplicativo seja fcil de
gerenciar e aprimorar. Cada um destes contextos tem uma
responsabilidade especfica, e pode operar de uma forma semiautnoma. Ao dividir estes em pedaos, torna-se mais bvio
para encontrar onde a lgica deve estar, e voc pode evitar
que BBOM (Big Ball of mud/Grande Bola de Lama)

O que BBOM?

O que BBOM?
Uma grande bola de lama (Big Ball of mud) uma forma
de estrutura anrquica, esparramada, desleixada, a selva
do cdigo espaguete. Estes sistemas mostram sinais
inequvocos de crescimento descontrolado, e repetida. A
informao

partilhada
promiscuamente
entre
elementos distantes do sistema, muitas vezes ao ponto
onde quase todas as informaes importantes torna-se
global ou duplicados. A estrutura geral do sistema pode
nunca ter sido bem definido.

O que BBOM?
Nosso objetivo todo o tempo deve ser o de evitar BBOM.
Novamente com o "Domnio: Edifcio Residencial". Ns
poderamos ter vrios contextos delimitadas:

Fornecimento de electricidade
Estacionamento
Apartamento
Etc.

Pergunta!

Pergunta!

Primeira pergunta: Voc pode imaginar uma janela sem

um cmodo?
Segunda pergunta: Ser que uma janela tem qualquer
identidade sem o cmodos que est residindo?

Antes, para responder essas perguntas vamos expor mais

alguns conceitos de DDD.

Entity.
Value Object.
Aggregates & Aggregate root.

Entidade

Entidade
"Esta a minha entidade, existem muitos como ele, mas este o
meu."
A caracterstica definidora chave de uma entidade que ele tem
uma identidade - nico dentro do sistema, e nenhuma outra
entidade, no importa o quo semelhante, a mesma entidade a
menos que tenha a mesma identidade.
Exemplos:

O seu quarto no apartamento.

O seu contrato no Facebook.
O meu celular.

Objeto de valor

Objeto de valor
A caracterstica definidora chave de um objeto de valor que
no tem identidade. Ok, talvez um pouco simplista, mas a
inteno de um objeto de valor representar algo apenas por
seus atributos. Dois objetos de valor podem ter seus atributos
iguais, nesse caso eles so idnticos. Eles no tm qualquer
valor que no seja em virtude de seus atributos. Outro aspecto
comum aos objetos de valor que eles devem provavelmente
ser imutveis, uma vez criados, eles no podem ser alterados.
Voc pode criar um novo, e como eles no tm identidade, que
exatamente oExemplo:
mesmo que mudar para outra.

Janelas dos cmodos

Endereo de qualquer pessoa em
seu site.
Campo de busca da sua pesquisa.

Objeto de valor
Agora voc sabe o que entidade , e o que o objeto de valor
no DDD. Nas entidades em DDD, objetos de valor podem existir
de forma independente. Mas, em alguns casos, a relao pode
ser tal que, uma entidade ou OV no tem valor sem o seu
contexto.
Exemplo:

Uma janela s pode ser definida, se houver um cmodo.

Um item de pedido s pode existir se houver um pedido
Uma resposta de uma questo s pode estar l se uma
pergunta feita.

Muito simples, no ? Acredite em mim, agora voc sabe o que

Aggregate e Aggregate Root est em DDD.

Aggregate e
Aggregate Root

Aggregate e Aggregate Root

Nos exemplos dados anteriormente:

Cmodo, pedido e pergunta so os nossos AGGREGATE ROOT.

Por outro lado a janela, item de pedido e a resposta so os
nossos AGGREGATE.

"Um conjunto de objetos associados que so tratados como uma

unidade no que diz respeito a alteraes de dados."
Todos os objetos do conjunto deve ser tratado como um agregado.
Todo o acesso externo ao conjunto atravs de uma entidade raiz
nica. Esta entidade raiz definido como aggregate root.

Aggregate e Aggregate Root

Exemplo:

Uma resposta deve de modo algum ser salvo, a menos que a

pergunta correspondente seja salva.
Uma resposta deve de modo algum ser recuperado, a menos
que a questo correspondente seja recuperada.

A Pergunta aqui O AGGREGATE ROOT e a resposta o

AGGREGATE. Agregados e agregados raizes so conceitos
importantes de DDD.
At agora, temos falado sobre domnio, objetos / entidades,
contextos, agregados etc. E sobre o banco de dados? algo que
ns tenhamos perdido? No algo que devemos ver no design?
A resposta no! DDD uma abordagem ignorante de
persistncia.