Você está na página 1de 5

capa

Guilherme Moreira Guilherme Prado


(guilherme.moreira@caelum.com.br): Coordenador e instrutor (guilherme.prado@caelum.com.br): Formado como Tcnico em
da Caelum em Braslia, um dos autores do livro "Arquitetura Processamento de Dados pelo CTI/UNESP. Instrutor da Caelum
e Design de Software Uma viso sobre a plataforma Java", em Braslia e Tcnico de Informtica do Conselho
trabalhando com Java desde 2005, com projetos em geral da Justia Federal. Trabalha com desenvolvimento de software
na parte web tanto para a Caelum quanto para os clientes da h 9 anos atuando principalmente com tecnologias Java, ASP,
mesma. Possui as certificaes SCJP e SCEA 5 e responsvel por PHP e VB.
alguns projetos open-source da Caelum, alm de desenvolver
cursos novos e material didtico.

Domain-Driven Design
Alm dos Patterns
O que se pode aprender do Livro de Eric Evans?

Domain-Driven Design , como o prprio nome


diz, observar o Design da aplicao pensando
no domnio. O objetivo deste artigo discutir
algumas ideias citadas no livro de Eric Evans a
respeito de como tratar o domnio de forma
coerente entre a equipe tcnica e a equipe que
entende do negcio.

esde o lanamento do livro Domain-Driven Design (de Eric

D Evans), a comunidade de desenvolvedores ganhou uma arma


poderosssima que refora uma maneira j (muito) discutida de
como desenvolver software com qualidade: as conversas entre
equipe de desenvolvimento e quem entende do negcio.

Como se viu em recente post do Philip Calado (link nas referncias),


podemos conferir que a busca por patterns do livro de Eric Evans (por
exemplo repository, anticorruption layer) muito maior que a busca por
seus conceitos principais (por exemplo, Ubiquitous Language). Por que
tanta procura por patterns? Onde se encaixa a Ubiquitous Language?

O objetivo deste artigo discutir temas como linguagem ubqua, design


patterns e outras ideias do livro de Eric Evans, tambm avaliando um
pouco das prticas do mercado em relao ao livro, alm de claro a parte
fundamental do livro, um pouco sobre a modelagem de domnio. No
comeo do artigo revisaremos alguns pontos fundamentais dos concei-
tos de DDD, passando pelas discusses sobre software versus conheci-
mento, juntando logo em seguida ao conceito de ubiquituos language,
mostrando os pontos fortes e fracos dessa prtica. Na segunda parte do
artigo discutido o papel de alguns Design Patterns em relao ao DDD
e seus conceitos

18 www.mundoj.com.br
Domain-Driven Design Alm dos Patterns

Revisando o conceito de Domain-Driven necessidades tcnicas do projeto e a equipe tcnica deve se esforar para
entender do negcio. Sem esse esforo de ambas as partes no sair um
Design modelo til.Esse modelo sofrer diversas mudanas com o passar do tem-
po, pois ele no ser perfeito na primeira tentativa e nem nas prximas. As
Softwares so feitos para melhorar ou ajudar algum processo que exista
equipes devem estar aptas s mudanas, tanto de regra, quanto de enten-
no mundo real. Se seguirmos essa linha de raciocnio, podemos pensar
dimento sobre o sistema. O modelo de qualidade deve ser algo malevel,
que os softwares partem de algo que j existe. Alguns softwares sero
que aceite evolues e regresses caso seja necessrio.
uma representao e outros vo auxiliar algo j existente. O conhecimen-
to sobre o mundo real deve estar embutido no software. No processo As duas equipes vo conseguir atingir um modelo de qualidade atravs
de criao de um sistema temos dois papis fundamentais: aquele que de muita conversa, transmisso de conhecimento, nas duas vias. Mas no
conhece o domnio muito bem e aquele que conhece a parte tcnica qualquer conversa que ser aproveitvel. Uma conversa produtiva ser
muito bem. Esses dois papis no podem de maneira nenhuma trabalhar aquela cujo resultado seja algo integrvel ao cdigo, sem nenhum inter-
separadamente. Quem entende do domnio precisa da equipe tcnica medirio. Os termos utilizados durante as reunies devem ser amplamente
para conseguir expressar seu conhecimento atravs de software e a aceitos, usados e entendidos, e a linguagem que os dois times usam deve
equipe tcnica precisa da equipe que entende do negcio para poder ser a mesma.
escrever um software til e de acordo com a necessidade.

Onde entra o Domain-Driven Design nisso?


A Ubiquitous Language
O Domain-Driven Design um conjunto de princpios que auxiliam o de- No s nas conversas essa linguagem deve estar presente, como os
senvolvimento de software voltado para o domnio, ou seja, voltado para termos empregados devero aparecer tambm no cdigo, nos e-mails
o processo que existe no mundo real, no ignorando o fato que esse do- trocados, nas reunies e em possveis documentaes. Essa linguagem
mnio ser expresso atravs de cdigo. Domain-Driven Design prega que deve ser nica e presente em todos os lugares. Nisso temos o conceito
para grande maioria dos projetos o foco deve ser o domnio da aplicao de linguagem ubqua ou em ingls ubiquitous language. Em um
e nas lgicas envolvidas nele e quando o domnio for complexo a base cenrio em que a linguagem nica, temos pontos muito fortes, como
do projeto deve ser um modelo baseado no domnio. Esse foco ajuda manuteno. Caso haja alguma mudana em alguma regra (e elas exis-
projetos de domnio complexos a acelerarem o andamento do projeto, tiro) quando ela for discutida, a mudana ser refletida nas conversas
mantendo uma organizao e uma base de discusso. e quase mais importante ainda, refletir no modelo. Consequentemen-
te, o cdigo dever ser refatorado para atender a este novo modelo.
Mas esse ganho no vem sem trabalho: o cenrio descrito a realidade
Conhecimento
de uma equipe madura e experiente com esse raciocnio.
Toda a base do Domain-Driven Design gira em torno do domnio e como
desenvolver sendo ele a parte principal da aplicao. O domnio o que d Dificuldades ao usar a Ubiquitous
valor aplicao; rea de conhecimento, atividade ou influncia na qual Language
o software aplicado. Este domnio no precisa, nem deve, ser represen-
tado com total fidelidade, ele deve ser refinado at chegar em um modelo O maior impedimento da linguagem ubqua a diferena entre as duas
que atenda s necessidades do cliente e que tambm seja implementvel, equipes em relao aos termos empregados. comum as equipes acabarem
isso declaradamente uma tarefa rdua de se completar. Pode-se definir desistindo de usar essa linguagem nica, pois uma equipe no entende os ter-
modelo como uma abstrao que descreve aspectos selecionados do mos usados pela outra, ou na tentativa de usar a linguagem, acabarem criando
domnio que so relevantes resoluo de problemas relacionados a ele. tradues para os termos. Essas tradues so um erro gravssimo, perder o
O principal na hora de trabalhar com Domain-Driven Desgin manter o sentido da linguagem nica. Essas tradues geram erros de interpretao que
foco no domnio, porm se este domnio representado atravs de um sero refletidos no cdigo. A linguagem ubqua deve ser consistente e livre de
modelo a importncia do DDD vista ao criar ao modelar o domnio. Nesta ambiguidades. Realmente, no adianta ter a equipe usando os mesmo termos
modelagem, o ponto fundamental destilar o conhecimento, os domain- quando cada pessoa entende o termo de maneira diferente (evitar ambigui-
experts, aqueles que entendem do negcio, vo sentar junto com a equipe dade), assim como apenas atrapalharia o andamento do projeto um conceito
tcnica, arquiteto, analista, programadores (s vezes nem todos os progra- sendo representado por dois termos diferentes (evitar inconsistncia).
madores) e montar um modelo que atenda s necessidades tcnicas, que
seja implementvel e que esteja de acordo com o negcio.
Distncia entre o modelo e o cdigo
O modelo
Ainda analisando mais sobre a linguagem ubqua, outro erro
O modelo no precisa ser um diagrama UML, ele pode ser qualquer tipo comum cometido por causa de dificuldades no caminho que
de artefato que reproduza o conhecimento gerado pelas equipes durante mesmo que as conversas, os termos, tudo seja baseado no modelo,
as conversas, ele pode ser uma documentao escrita, um desenho ou um o cdigo no seja uma representao prxima do modelo. Mesmo
diagrama feito a mo com anotaes sobre o que cada parte significa e o modelo sendo til para discutir novas funcionalidades, logo que
como elas se juntam. A qualidade do modelo depende muito das duas o cdigo comear a ser escrito ele ficar defasado e inconsistente,
equipes. Depende da equipe de domains-experts saber transmitir o conhe-
ele perder sua principal funo: ser a ponte entre o conhecimento
cimento de forma clara e compreensvel e depende da equipe tcnica que
das equipes e o cdigo. Um modelo que no representa o cdigo,
dar veracidade tcnica para ele. Os domains-experts devem entender as
segundo Evans intil.

19
$BQBt%PNBJO%SJWFO%FTJHO"MNEPT1BUUFSOT

Encarando Design Patterns atravs dos Os patterns so consequncias dos conceitos. DDD no um catlogo de
patterns, tanto que alguns patterns citados por Evans j existiam muito antes
conceitos do livro (alguns deles no livro Patterns of Enterprise Application Archtecture
de Martin Fowler). Os patterns devem surgir com naturalidade.
A linguagem ubqua deve ser baseada no conhecimento gerado pelas
equipes, trabalhada, at chegar em um modelo til e de qualidade. Esse Inclusive no livro Evans evita-se chamar Repository e Domain-Model de
modelo deve ser legvel pelas duas equipes. Patterns para evitar esteritipos, porm os dois so padres documenta-
dos por Fowler.
Juntando a ideia de encapsulamento da orientao a objetos com este
modelo, resulta que, ao olhar para o modelo, o programador no deve
precisar ver sua implementao para descobrir o que ele faz, a sua funo Um pouco sobre DDD em larga escala
deve estar bem clara. Esta a ideia do Supple Pattern Intention-reve-
Em quais tipos de sistema que o Domain-Driven Design vantajoso? Essa
aling Interfaces, interfaces que revelam suas intenes sem olhar para
uma pergunta bem difcil de responder. Em geral, sistemas onde o objetivo
a implementao. Falar sobre encapsulamento hoje em dia uma ideia
no apenas guardar e mostrar dados, mas que envolvam algumas regras
batida para a maioria dos desenvolvedores, mas podemos falar em dois
mais complexas e domnios ricos podero tirar mais conselhos do livro. Po-
nveis de encapsulamento: por cdigo e por leitura. O encapsulamento
rm, todo sistema pode tirar vantagem das prticas do DDD, nem que seja
por cdigo seria mais o cdigo que chama um mtodo no depender da
apenas como comear a conversa com o cliente e manter um modelo imple-
implementao dele, mas o desenvolvedor ainda sim seria obrigado a
mentvel. Alis, todas as equipes de desenvolvimento podem tirar lies do
conhecer a implementao para saber o que fazer, e isso praticamente no
livro, um livro importante na vida dos desenvolvedores.
encapsulamento. Intention-reveling Interfaces est mais voltado para
a leitura do cdigo, nada mais prazeroso que olhar para uma interface e Nem todo sistema precisa ser colossal para se comear a pensar em DDD.
entend-la sem nunca se preocupar com sua implementao. Esse um Na verdade, para chegar a um sistema colossal, deveramos comear com
timo exemplo de linguagem ubqua pensada junto com cdigo. um sistema mnimo e expandi-lo para onde for necessrio, em etapas (ou
iteraes, dependendo da metodologia que estiver trabalhando).
Durante o livro, Evans cita diversos exemplos de bons usos para a lin-
guagem ubqua, direta ou indiretamente. Tanto na Parte III (Refactoring Depois que o sistema estiver maior, os tipos de problemas apresentados
toward deeper Insight), como na Parte II (The Building Blocks of sero outros, e surgiro principalmente problemas de comunicao entre as
Model-Driven Design). Mesmo quando so listados alguns Design Pat- equipes e os desenvolvedores. Nesse caso, provavelmente, muitos modelos
terns, Evans sempre preza o Design do modelo com a implementao. estaro em jogo e inevitvel que este tipo de problema aparea.

Mais um exemplo de Pattern visto atravs Trabalhando com diversos modelos, pode-se ter cada parte da equipe
da modelagem do negcio trabalhando em cada um deles. Onde comea e termina o trabalho de uma
equipe sem que atrase a outra? No h uma frmula mgica para evitar
Acredito que a palavra repository tenha um sentido mais comum para as isso, o que pode ser feito deixar bem claro e delimitado at onde cada um
pessoas que falam ingls, pois em portugus a palavra repositrio no faz desses modelos vai trabalhar. Essa delimitao o que no livro chamado de
parte do vocabulrio da maioria das pessoas (inclusive do meu), ento como bounded contexts (contextos delimitados).
explicar para um domain-expert por que no modelo temos ContatoRepo-
O conceito de bounded contexts fica em um captulo do livro chamado
sitorio? No precisa, no importa o nome dado classe, desde que atravs
Maintaining Model Integrity, e serve para quando o sistema fica muito
desse nome seja possvel enxergar que aquela parte do sistema respon-
grande, porm o assunto se encaixaria tambm no captulo Large-Scale
svel por guardar certos tipos de coisas (objetos) e recuper-los quando
Structure. O captulo Large-Scale Structure mais focado em discutir ideias
necessrio. Esses so os repositrios. Neles usamos termos conhecidos pela
e padres para sistemas muito grandes que vo precisar ir alm de uma
linguagem ubqua e no modelo, no importa quais sejam, se precisarmos
estrutura apenas malevel. Por exemplo, comenta-se a ideia de manter uma
guardar alguma coisa para isso que os repositrios aparecero. Muitas
arquitetura que possa evoluir junto do sistema. Evans chama esse conceito
vezes os repositrios sero apenas interfaces (caso voc esteja trabalhando
de Evolving Order. A discusso neste captulo gira em torno da funo de
com Java), outras sero classes que delegam o trabalho para outras classes.
uma arquitetura de software.

interface AgendaDeContatos{ Por um lado, podemos ter uma arquitetura completamente restritiva, que
List<Contato> buscarContatosQueComecaoCom(String comeco); obrigue o modelo a sofrer srias consequncias, como acabar por criar um
List<Contato> buscarContatosQueContenha(String trecho); modelo anmico, sem inteligncia nenhuma (ver referncias do artigo),
Contato buscarContatoAtravesDeId(Long id);
e que no fique livre para evoluir e acatar os novos insights (novos enten-
}
dimentos sobre o domnio) que surgirem durante a produo do sistema,
Assim como o livro Design Patterns, o livro Domain-Driven Design tambm mas que resolva diversas questes tcnicas como persistncia, mensageria e
tem feito o mesmo sucesso, mas parece que ambos so lidos e tratados rede. Porm, por outro lado, se tivermos uma arquitetura muito aberta onde
muitas vezes apenas como um catlogo de patterns. No livro do Gang of cada desenvolvedor tem a chance de escolher coisas muito diferentes do res-
Four, onde os dois captulos iniciais apresentam conceitos fundamentais at to do projeto, quanto mais o sistema crescer, mais o desenvolvimento ficar
mais importantes que os prprios patterns, o DDD tambm deve ter seus completamente desordenado e de baixa manutenibilidade, com diversas
conceitos muito bem explorados e os patterns devem ser enxergados como solues para as mesmas questes espalhadas pelo cdigo.
exemplificao destes.
Um timo exemplo de arquitetura restritiva o J2EE 1.4. Ao criar um session

20 www.mundoj.com.br
$BQBt%PNBJO%SJWFO%FTJHO"MNEPT1BUUFSOT

bean era obrigatrio implementar diversos mtodos que no faziam o me- Na camada aplicao ficam as operaes de coordenao da aplicao e
nor sentido para qualquer negcio. suporte a outras tarefas tcnicas. Aqui disparada a lgica de negcio que
est em outra camada, ou chamada alguma tarefa tcnica de banco de
public class VendaBean implements SessionBean{ dados, como o incio de uma transao e seu respectivo final. Qualquer dado
public void vender(Produto produto){ que a camada de domnio precisar para iniciar a operao de responsa-
// bilidade da aplicao busc-lo. A palavra-chave para entender a camada de
}
aplicao quando ela sabe quando disparar as coisas, mas no sabe como.
//mtodos de origem exclusivamente tcnica
public void setSessionContext(SessionContext ctx){}
A camada de domnio o corao do software, aqui que est toda a regra
public void ejbActivate(){}
public void ejbPassivate(){} discutida nas conversas, aqui que o modelo representado em cdigo usan-
public void ejbCreate(){} do a linguagem ubqua. esta camada que d valor aplicao, ela iterage
public void ejbRemove(){} com todas as camadas da aplicao, ela recebe chamadas da camada de
} aplicao, devolve valores para a camada de interface com o usurio (esses
valores podem passar pela camada de aplicao) e dispara requisies para
Uma proposta em Evolving Order praticar uma arquitetura que no seja a camada de infraestrutura.
fixa, que ela possa evoluir com as necessidades que forem surgindo no ca-
minho, mesmo que ela tenha que mudar completamente para se encaixar Toda parte tcnica do sistema, banco de dados, bibliotecas, e-mail, fra-
melhor no sistema. O arquiteto e o gerente do sistema devem estar aptos a meworks, renderizao de componentes fazem parte da infraestrutura da
conversar com a equipe e ponderar quando mudar a arquitetura e quando aplicao. Esses detalhes tcnicos ficam contidos na camada de infraes-
deixar que o modelo sofra as consequncias. Percebam que nem sempre trutura, ela serve para isolar o resto da aplicao desses detalhes. Um caso
mudar a arquitetura a melhor soluo; essa uma das principais funes interessante na camada de infraestrutura que mesmo os componentes
dos arquitetos: ponderar os trade-off's que as mudanas causaro. desenvolvidos internamente na empresa ficam nessa camada, permitindo
uma maior reusabilidade dos componentes.
No fcil tomar deciso arquiteturais que sirvam para toda a vida do proje-
to. Por isso, a ideia de evoluir a arquitetura conforme a necessidade. Para que
isso seja possvel, necessrio que principalmente o domnio esteja desaco- User Interface
plado de qualquer questo tcnica ou da comunicao com o usurio. Esse (Interface com o usurio)
isolamento do domnio, aliado a separao de questes de infraestrutura
e de comunicao com o usurio outro conceito fundamental do DDD, a
arquitetura de camadas ou a Layered Architecture.
Application
(aplicao)
Layered Architecture
Uma boa prtica aplicada h muito tempo no Java a diviso do sistema
em camadas, por responsabilidade, aqui cabe lembrar do MVC, que a Domain
diviso entre os objetos da camada do modelo, camada da visualizao e (domnio)
camada de controle. Na DDD a arquitetura proposta muda um pouquinho
do MVC, embora conceitualmente as duas divises eles sejam bem pareci-
dos, algumas questes tcnicas fazem com que elas sejam diferentes.
Infrastructure
A diviso proposta por Evans foca muito no conceito fundamental do DDD, (Infra-estrutura)
o domnio. Essa arquitetura de camadas sugere isolar o domnio de qual-
'JHVSB%JWJTPFNDBNBEBTEPTJTUFNB
quer outra camada, deix-lo o mais puro possvel, j que o prprio domnio
j ser suficientemente complexo para tambm ter que lidar com outras
A importncia da arquitetura de camadas no est s na reusabilidade
questes, como tcnica ou da camada visual. A camada de domnio onde
dos componentes ou na opo de ter uma arquitetura que evolua junto
o modelo representado, as outras camadas so auxiliar desta. No pense
da aplicao, sua importncia devido manutenibilidade que ela ofere-
que s porque essas camadas so auxiliares elas no so importantes, sem
elas a aplicao no rodaria, um modelo sem uma infraestrutura por baixo ce, muito mais simples procurar um bug de lgica de negcio quando o
ou uma camada de apresentao para o usurio no faria sentido. domnio est isolado, do que procurar esse bug no meio de uma monte
de cdigo de tela junto com o cdigo de negcio.
Ao todo o sistema fica dividido em quatro partes: User Interface (interface
com o usurio), Application (Aplicao), Domain (Domnio) e Infrastruc- Assim como a maioria das arquiteturas de camada para que ela seja efe-
ture (infraestrutura) ver figura 1. tiva as camadas devem seguir algumas premissas: estar completamente
desassociada uma da outra se comunicando sempre atravs de interfaces
A camada de interface com o usurio fica responsvel, assim como no e a camada inferior nunca disparar operaes na camada superior, ima-
MVC, de se comunicar com o usurio, tanto para receber comando como gine uma busca no banco de dados disparando operaes de negcio,
mostrar resultados, o usurio no precisa necessariamente ser uma pessoa, em um sistema muito grande achar quem dispara essa operao seria
pode at ser outro sistema (web-services, motores de indexao etc.). extremamente complexo.

21
$BQBt%PNBJO%SJWFO%FTJHO"MNEPT1BUUFSOT

Concluso
Para saber mais
Voc no deixar de usar Domain-Driven Design se seu cdigo no tiver
a palavra repositrio ou anti-corruption layer. Patterns mudam com o No deixe de conferir mais sobre os conceitos deste artigo no artigo
tempo; hoje eles so boas prticas, amanh talvez nem tanto. O concei- do Srgio Lopes na edio nmero 31 da Mundoj, no artigo "Criando
to principal DDD no so os patterns ou usar ou no todos os building Software mais Prximo do Cliente com Domain-Driven Design.
blocks e sim pensar no domnio para chegar em um modelo rico de
conhecimento e implementvel, atravs de muita comunicao.

No por isso que devemos deixar de aprender design patterns. Eles


Referncias
so uma tima fonte de ideias de como resolver problemas comuns do
dia-a-dia, com o aval de muita gente que j usou aquela soluo. Porm, t1PTUOP#MPHEP1IJMJQ$BMBEP FNJOHMT

IUUQGSBHNFOUBMUXOFWFSNJOEEPNBJOESJWFOEFTJHO
os patterns no devem ser encarados como mais do que isso, mas sim, t1PTUOP#MPHEB$BFMVNTPCSF%FTJHO1BUUFSOT
como artifcios que permitem que o modelo de domnio seja implemen- IUUQCMPHDBFMVNDPNCSEFTJHOQBUUFSOTVNNBVTJOBM
tado de forma mais eficiente, assim como as outras camadas do estilo de t1PTUOP#MPHEF.BSUJO'PXMFSTPCSF.PEFMP"ONJDP FNJOHMT
IUUQNBSUJOGPXMFS
com/bliki/AnemicDomainModel.html
arquitetura proposta por Eric Evans. t&SJD&WBOTo%PNBJO%SJWFO%FTJHO5BDLMJOH$PNQMFYJUZJOUIF)FBSUPG4PGUXBSF
t"CFM"WSBNF'MPZE.BSJOFTDVo%PNBJO%SJWFO%FTJHO2VJDLMZ
t&SJDI(BNNBo%FTJHO1BUUFSOT&MFNFOUTPG3FVTBCMF0CKFDU0SJFOUFE4PGUXBSF

22 www.mundoj.com.br