You are on page 1of 5

capa

Guilherme Moreira Guilherme Prado
(guilherme.moreira@caelum.com.br): Coordenador e instrutor (guilherme.prado@caelum.com.br): Formado como Técnico em
da Caelum em Brasília, é um dos autores do livro "Arquitetura Processamento de Dados pelo CTI/UNESP. Instrutor da Caelum
e Design de Software – Uma visão sobre a plataforma Java", em Brasília e Técnico de Informática do Conselho
trabalhando com Java desde 2005, com projetos em geral da Justiça 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 certificações SCJP e SCEA 5 e é responsável por PHP e VB.
alguns projetos open-source da Caelum, além de desenvolver
cursos novos e material didático.

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

Domain-Driven Design é, como o próprio nome
diz, observar o Design da aplicação pensando
no domínio. O objetivo deste artigo é discutir
algumas ideias citadas no livro de Eric Evans a
respeito de como tratar o domínio de forma
coerente entre a equipe técnica e a equipe que
entende do negócio.

esde o lançamento do livro Domain-Driven Design (de Eric

D Evans), a comunidade de desenvolvedores ganhou uma arma
poderosíssima que reforça uma maneira já (muito) discutida de
como desenvolver software com qualidade: as conversas entre
equipe de desenvolvimento e quem entende do negócio.

Como se viu em recente post do Philip Calçado (link nas referências),
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 ubíqua, design
patterns e outras ideias do livro de Eric Evans, também avaliando um
pouco das práticas do mercado em relação ao livro, além de claro a parte
fundamental do livro, um pouco sobre a modelagem de domínio. No
começo do artigo revisaremos alguns pontos fundamentais dos concei-
tos de DDD, passando pelas discussões sobre software versus conheci-
mento, juntando logo em seguida ao conceito de ubiquituos language,
mostrando os pontos fortes e fracos dessa prática. Na segunda parte do
artigo é discutido o papel de alguns Design Patterns em relação ao DDD
e seus conceitos

18 www.mundoj.com.br

e a linguagem que os dois times usam deve equipe técnica precisa da equipe que entende do negócio para poder ser a mesma. O conhecimen- to sobre o mundo real deve estar embutido no software. As Softwares são feitos para melhorar ou ajudar algum processo que exista equipes devem estar aptas às mudanças. acabarem criando domínio que são relevantes à resolução de problemas relacionados a ele. vão sentar junto com a equipe dade). tanto de regra. ou seja. madores) e montar um modelo que atenda às necessidades técnicas. Nisso temos o conceito para grande maioria dos projetos o foco deve ser o domínio da aplicação de linguagem ubíqua ou em inglês ubiquitous language. Mesmo diagrama feito a mão com anotações sobre o que cada parte significa e o modelo sendo útil para discutir novas funcionalidades. pois uma equipe não entende os ter- modelo como uma abstração que descreve aspectos selecionados do mos usados pela outra. Sem esse esforço de ambas as partes não sairá um Design modelo útil. Domain-Driven Design Além dos Patterns Revisando o conceito de Domain-Driven necessidades técnicas do projeto e a equipe técnica deve se esforçar para entender do negócio. Realmente. tudo seja baseado no modelo. a mudança será refletida nas conversas mantendo uma organização e uma base de discussão. usados e entendidos. voltado para termos empregados deverão aparecer também no código. refletirá no modelo. Essas traduções geram erros de interpretação que foco no domínio. No processo As duas equipes vão conseguir atingir um modelo de qualidade através de criação de um sistema temos dois papéis fundamentais: aquele que de muita conversa. como os senvolvimento de software voltado para o domínio. nem deve. traduções para os termos. Se seguirmos essa linha de raciocínio. Este domínio não precisa. ou na tentativa de usar a linguagem. transmissão de conhecimento. Nesta ambiguidades. Os domains-experts devem entender as segundo Evans é inútil. Caso haja alguma mudança em alguma regra (e elas exis- projetos de domínio complexos a acelerarem o andamento do projeto. equipes em relação aos termos empregados. Alguns softwares serão que aceite evoluções e regressões caso seja necessário. Onde entra o Domain-Driven Design nisso? A Ubiquitous Language O Domain-Driven Design é um conjunto de princípios que auxiliam o de. Uma conversa produtiva será muito bem. as conversas. escrever um software útil e de acordo com a necessidade. Os termos utilizados durante as reuniões devem ser amplamente para conseguir expressar seu conhecimento através de software e a aceitos. Toda a base do Domain-Driven Design gira em torno do domínio e como desenvolver sendo ele a parte principal da aplicação. sendo representado por dois termos diferentes (evitar inconsistência). quando cada pessoa entende o termo de maneira diferente (evitar ambigui- experts. Um modelo que não representa o código. é área de conhecimento. Distância entre o modelo e o código O modelo Ainda analisando mais sobre a linguagem ubíqua. quanto de enten- no mundo real. pois ele não será perfeito na primeira tentativa e nem nas próximas. ele pode ser uma documentação escrita. 19 . um desenho ou um o código não seja uma representação próxima do modelo. o ponto fundamental é destilar o conhecimento. uma representação e outros vão auxiliar algo já existente. Esses dois papéis não podem de maneira nenhuma trabalhar aquela cujo resultado seja algo integrável ao código. dará veracidade técnica para ele. Esse foco ajuda manutenção. os termos. trocados. podemos pensar dimento sobre o sistema. 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. é perder o O principal na hora de trabalhar com Domain-Driven Desgin é manter o sentido da linguagem única. como do projeto deve ser um modelo baseado no domínio. Quem entende do domínio precisa da equipe técnica mediário. sem nenhum inter- separadamente.Esse modelo sofrerá diversas mudanças com o passar do tem- po. analista. A qualidade do modelo depende muito das duas o código começar a ser escrito ele ficará defasado e inconsistente. não ignorando o fato que esse do. os domain. aqueles que entendem do negócio. ele deve ser refinado até chegar em um modelo O maior impedimento da linguagem ubíqua é a diferença entre as duas que atenda às necessidades do cliente e que também seja implementável. que os softwares partem de algo que já existe. nos e-mails o processo que existe no mundo real. porém se este domínio é representado através de um serão refletidos no código. programadores (às vezes nem todos os progra. ser represen- tado com total fidelidade. nas reuniões e em possíveis documentações. o código deverá ser refatorado para atender a este novo modelo. Consequentemen- te. O modelo de qualidade deve ser algo maleável. arquiteto. não adianta ter a equipe usando os mesmo termos modelagem. Pode-se definir desistindo de usar essa linguagem única. Essa linguagem mínio será expresso através de código. logo que como elas se juntam. Essas traduções são um erro gravíssimo. Depende da equipe de domains-experts saber transmitir o conhe- ele perderá sua principal função: ser a ponte entre o conhecimento cimento de forma clara e compreensível e depende da equipe técnica que das equipes e o código. atividade ou influência na qual Language o software é aplicado. Mas não conhece o domínio muito bem e aquele que conhece a parte técnica é qualquer conversa que será aproveitável. equipes. A linguagem ubíqua deve ser consistente e livre de modelo a importância do DDD é vista ao criar ao modelar o domínio. Domain-Driven Design prega que deve ser única e presente em todos os lugares. temos pontos muito fortes. outro erro O modelo não precisa ser um diagrama UML. tirão) quando ela for discutida. O domínio é o que dá Dificuldades ao usar a Ubiquitous valor à aplicação. Não só nas conversas essa linguagem deve estar presente. que seja implementável e que esteja de acordo com o negócio. Em um e nas lógicas envolvidas nele e quando o domínio for complexo a base cenário em que a linguagem é única. Mas esse ganho não vem sem trabalho: o cenário descrito é a realidade Conhecimento de uma equipe madura e experiente com esse raciocínio. assim como apenas atrapalharia o andamento do projeto um conceito técnica. nas duas vias. É comum as equipes acabarem isso é declaradamente uma tarefa árdua de se completar. e quase mais importante ainda.

Falar sobre encapsulamento hoje em dia é uma ideia não é apenas guardar e mostrar dados. mas podemos falar em dois mais complexas e domínios ricos poderão tirar mais conselhos do livro. Mais um exemplo de Pattern visto através Trabalhando com diversos modelos. então como bounded contexts (contextos delimitados). o DDD também deve ter seus completamente desordenado e de baixa manutenibilidade. estarão em jogo e é inevitável que este tipo de problema apareça.br . porém os dois são padrões documenta- dos por Fowler. Contato buscarContatoAtravesDeId(Long id). e serve para quando o sistema fica muito desse nome seja possível enxergar que aquela parte do sistema é respon- grande. DDD não é um catálogo de patterns. não importa o nome dado à classe. Assim como o livro Design Patterns. Onde começa e termina o trabalho de uma equipe sem que atrase a outra? Não há uma fórmula mágica para evitar Acredito que a palavra repository tenha um sentido mais comum para as isso. Esse Inclusive no livro Evans evita-se chamar Repository e Domain-Model de modelo deve ser legível pelas duas equipes. Mesmo quando são listados alguns Design Pat. 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). mas que envolvam algumas regras batida para a maioria dos desenvolvedores. provavelmente. por outro lado. mas parece que ambos são lidos e tratados rede. explicar para um domain-expert por que no modelo temos ContatoRepo- O conceito de bounded contexts fica em um capítulo do livro chamado sitorio? Não precisa. obrigue o modelo a sofrer sérias consequências. sem inteligência nenhuma (ver referências do artigo). $BQBt%PNBJO%SJWFO%FTJHO"MÏNEPT1BUUFSOT Encarando Design Patterns através dos Os patterns são consequências dos conceitos. e surgirão principalmente problemas de comunicação entre as Model-Driven Design). como na Parte II (The Building Blocks of serão outros. deveríamos começar com ótimo exemplo de linguagem ubíqua pensada junto com código. Tanto na Parte III (Refactoring Depois que o sistema estiver maior. todo sistema pode tirar vantagem das práticas do DDD. Aliás. O capítulo Large-Scale Structure é mais focado em discutir ideias necessário.4. não importa quais sejam. outras serão classes que delegam o trabalho para outras classes. até chegar em um modelo útil e de qualidade. nem que seja por código seria mais o código que chama um método não depender da apenas como começar a conversa com o cliente e manter um modelo imple- implementação dele. Ao criar um session 20 www. sistemas onde o objetivo a implementação. Juntando a ideia de encapsulamento da orientação a objetos com este modelo. direta ou indiretamente.mundoj. A discussão neste capítulo gira em torno da função de com Java). é encapsulamento. Muitas arquitetura que possa evoluir junto do sistema. interface AgendaDeContatos{ Por um lado. Essa delimitação é o que no livro é chamado de parte do vocabulário da maioria das pessoas (inclusive do meu). quanto mais o sistema crescer. a sua função Um pouco sobre DDD em larga escala deve estar bem clara. interfaces que revelam suas intenções sem olhar para uma pergunta bem difícil de responder. A linguagem ubíqua deve ser baseada no conhecimento gerado pelas equipes. Evans cita diversos exemplos de bons usos para a lin- guagem ubíqua. nada mais prazeroso que olhar para uma interface e Nem todo sistema precisa ser colossal para se começar a pensar em DDD. todas as equipes de desenvolvimento podem tirar lições do conhecer a implementação para saber o que fazer. Patterns para evitar esteriótipos. desde que através Maintaining Model Integrity. No livro do Gang of cada desenvolvedor tem a chance de escolher coisas muito diferentes do res- Four. onde os dois capítulos iniciais apresentam conceitos fundamentais até to do projeto. podemos ter uma arquitetura completamente restritiva. Esse é um Na verdade. entendê-la sem nunca se preocupar com sua implementação. o livro Domain-Driven Design também mas que resolva diversas questões técnicas como persistência. Esses são os repositórios. Os patterns devem surgir com naturalidade. em etapas (ou iterações. Neles usamos termos conhecidos pela e padrões para sistemas muito grandes que vão precisar ir além de uma linguagem ubíqua e no modelo. resulta que. um sistema mínimo e expandi-lo para onde for necessário. uma arquitetura de software. mais o desenvolvimento ficará mais importantes que os próprios patterns. equipes e os desenvolvedores. como acabar por criar um List<Contato> buscarContatosQueContenha(String trecho). o que pode ser feito é deixar bem claro e delimitado até onde cada um pessoas que falam inglês. o programador não deve precisar ver sua implementação para descobrir o que ele faz. é um livro importante na vida dos desenvolvedores. para chegar a um sistema colossal. e que não fique livre para evoluir e acatar os novos insights (novos enten- } dimentos sobre o domínio) que surgirem durante a produção do sistema. pois em português a palavra repositório não faz desses modelos vai trabalhar. Um ótimo exemplo de arquitetura restritiva é o J2EE 1. exemplificação destes. Porém. O encapsulamento rém. Evans chama esse conceito vezes os repositórios serão apenas interfaces (caso você esteja trabalhando de Evolving Order. trabalhada. muitos modelos terns. Evans sempre preza o Design do modelo com a implementação. comenta-se a ideia de manter uma guardar alguma coisa é para isso que os repositórios aparecerão. pode-se ter cada parte da equipe da modelagem do negócio trabalhando em cada um deles. ao olhar para o modelo. modelo anêmico. Durante o livro. se precisarmos estrutura apenas maleável. que List<Contato> buscarContatosQueComecaoCom(String comeco). e isso praticamente não livro. Esta é a ideia do Supple Pattern “Intention-reve- Em quais tipos de sistema que o Domain-Driven Design é vantajoso? Essa é aling Interfaces”. porém o assunto se encaixaria também no capítulo Large-Scale sável por guardar certos tipos de coisas (objetos) e recuperá-los quando Structure. mensageria e tem feito o mesmo sucesso. Nesse caso. dependendo da metodologia que estiver trabalhando).com. Em geral. Po- níveis de encapsulamento: por código e por leitura. Por exemplo. se tivermos uma arquitetura muito aberta onde muitas vezes apenas como um catálogo de patterns. Intention-reveling Interfaces está mais voltado para a leitura do código. os tipos de problemas apresentados toward deeper Insight). com diversas conceitos muito bem explorados e os patterns devem ser enxergados como soluções para as mesmas questões espalhadas pelo código. mas o desenvolvedor ainda sim seria obrigado a mentável.

Qualquer dado public void vender(Produto produto){ que a camada de domínio precisar para iniciar a operação é de responsa- // bilidade da aplicação buscá-lo. bibliotecas. é necessário que principalmente o domínio esteja desaco. aliado a separação de questões de infraestrutura e de comunicação com o usuário é outro conceito fundamental do DDD. Não é fácil tomar decisão arquiteturais que sirvam para toda a vida do proje- to. suporte a outras tarefas técnicas. é aqui que está toda a regra public void ejbActivate(){} public void ejbPassivate(){} discutida nas conversas. aqui cabe lembrar do MVC. Esse (Interface com o usuário) isolamento do domínio. Aqui é disparada a lógica de negócio que está em outra camada. mas não sabe como. como o início de uma transação e seu respectivo final. o usuário não precisa necessariamente ser uma pessoa. $BQBt%PNBJO%SJWFO%FTJHO"MÏNEPT1BUUFSOT bean era obrigatório implementar diversos métodos que não faziam o me. fra- melhor no sistema. a ideia de evoluir a arquitetura conforme a necessidade. domínio está isolado. as outras camadas são auxiliar desta. renderização de componentes fazem parte da infraestrutura da conversar com a equipe e ponderar quando mudar a arquitetura e quando aplicação. motores de indexação etc. de se comunicar com o usuário. que ela possa evoluir com as necessidades que forem surgindo no ca- minho. É esta camada que dá valor à aplicação. aqui que o modelo é representado em código usan- public void ejbCreate(){} do a linguagem ubíqua. e-mail. Essa arquitetura de camadas sugere isolar o domínio de qual- 'JHVSB%JWJTÍPFNDBNBEBTEPTJTUFNB quer outra camada. Application (Aplicação). assim como no e a camada inferior nunca disparar operações na camada superior. sem elas a aplicação não rodaria. algumas questões técnicas fazem com que elas sejam diferentes. desenvolvidos internamente na empresa ficam nessa camada. camada da visualização e (domínio) camada de controle. A palavra-chave para entender a camada de } aplicação é quando ela sabe quando disparar as coisas. ela recebe chamadas da camada de } aplicação. O arquiteto e o gerente do sistema devem estar aptos a meworks. ela iterage public void ejbRemove(){} com todas as camadas da aplicação. Domain (Domínio) e Infrastruc. embora conceitualmente as duas divisões eles sejam bem pareci- dos. Percebam que nem sempre trutura. por responsabilidade. do que procurar esse bug no meio de uma monte de código de tela junto com o código de negócio. //métodos de origem exclusivamente técnica public void setSessionContext(SessionContext ctx){} A camada de domínio é o coração do software. Application (aplicação) Layered Architecture Uma boa prática aplicada há muito tempo no Java é a divisão do sistema em camadas. essa é uma das principais funções interessante na camada de infraestrutura é que mesmo os componentes dos arquitetos: ponderar os trade-off's que as mudanças causarão. User Interface plado de qualquer questão técnica ou da comunicação com o usuário. já que o próprio domínio já será suficientemente complexo para também ter que lidar com outras A importância da arquitetura de camadas não está só na reusabilidade questões. Na DDD a arquitetura proposta muda um pouquinho do MVC. deixá-lo o mais puro possível. em um sistema muito grande achar quem dispara essa operação seria pode até ser outro sistema (web-services. (Infra-estrutura) o domínio. devolve valores para a camada de interface com o usuário (esses valores podem passar pela camada de aplicação) e dispara requisições para Uma proposta em Evolving Order é praticar uma arquitetura que não seja a camada de infraestrutura. permitindo uma maior reusabilidade dos componentes. tanto para receber comando como gine uma busca no banco de dados disparando operações de negócio. que é a Domain divisão entre os objetos da camada do modelo. Esses detalhes técnicos ficam contidos na camada de infraes- deixar que o modelo sofra as consequências. é muito mais simples procurar um bug de lógica de negócio quando o ou uma camada de apresentação para o usuário não faria sentido. mostrar resultados. mesmo que ela tenha que mudar completamente para se encaixar Toda parte técnica do sistema. tiva as camadas devem seguir algumas premissas: estar completamente desassociada uma da outra se comunicando sempre através de interfaces A camada de interface com o usuário fica responsável. ou é chamada alguma tarefa técnica de banco de public class VendaBean implements SessionBean{ dados. banco de dados. um modelo sem uma infraestrutura por baixo ce. Infrastructure A divisão proposta por Evans foca muito no conceito fundamental do DDD. a arquitetura de camadas ou a Layered Architecture. sua importância é devido à manutenibilidade que ela ofere- que só porque essas camadas são auxiliares elas não são importantes. fixa.). Um caso mudar a arquitetura é a melhor solução. extremamente complexo. 21 . Assim como a maioria das arquiteturas de camada para que ela seja efe- ture (infraestrutura) ver figura 1. Na camada aplicação ficam as operações de coordenação da aplicação e nor sentido para qualquer negócio. Para que isso seja possível. Não pense da aplicação. ela serve para isolar o resto da aplicação desses detalhes. como técnica ou da camada visual. Por isso. Ao todo o sistema fica dividido em quatro partes: User Interface (interface com o usuário). A camada de domínio é onde dos componentes ou na opção de ter uma arquitetura que evolua junto o modelo é representado. ima- MVC.

Eles Referências são uma ótima fonte de ideias de como resolver problemas comuns do dia-a-dia. blocks e sim pensar no domínio para chegar em um modelo rico de conhecimento e implementável. no artigo "Criando to principal DDD não são os patterns ou usar ou não todos os building Software mais Próximo do Cliente com Domain-Driven Design”. assim como as outras camadas do estilo de t1PTUOP#MPHEF.PEFMP"OÐNJDP FNJOHMÐT IUUQNBSUJOGPXMFS com/bliki/AnemicDomainModel.com. do Sérgio Lopes na edição número 31 da Mundoj. t&SJD&WBOTo%PNBJO%SJWFO%FTJHO5BDLMJOH$PNQMFYJUZJOUIF)FBSUPG4PGUXBSF t"CFM"WSBNF'MPZE. Patterns mudam com o Não deixe de conferir mais sobre os conceitos deste artigo no artigo tempo. hoje eles são boas práticas.BSUJO'PXMFSTPCSF. Não é por isso que devemos deixar de aprender design patterns. Porém.html arquitetura proposta por Eric Evans. através de muita comunicação.br . amanhã talvez nem tanto. $BQBt%PNBJO%SJWFO%FTJHO"MÏNEPT1BUUFSOT Conclusão Para saber mais Você não deixará de usar Domain-Driven Design se seu código não tiver a palavra repositório ou anti-corruption layer. com o aval de muita gente que já usou aquela solução. IUUQCMPHDBFMVNDPNCSEFTJHOQBUUFSOTVNNBVTJOBM tado de forma mais eficiente. t1PTUOP#MPHEP1IJMJQ$BMÎBEP FNJOHMÐT  IUUQGSBHNFOUBMUXOFWFSNJOEEPNBJOESJWFOEFTJHO os patterns não devem ser encarados como mais do que isso. t1PTUOP#MPHEB$BFMVNTPCSF%FTJHO1BUUFSOT como artifícios que permitem que o modelo de domínio seja implemen. mas sim.BSJOFTDVo%PNBJO%SJWFO%FTJHO2VJDLMZ t&SJDI(BNNBo%FTJHO1BUUFSOT&MFNFOUTPG3FVTBCMF0CKFDU0SJFOUFE4PGUXBSF 22 www.mundoj. O concei.