What Is Domain-Driven Design

O desenvolvimento de software é mais frequentemente aplicado a automatizar processos

que existem no mundo real, ou fornecer soluções aos problemas de negócio reais; Os
processos do negócio que estão sendo automatizados ou problemas reais do mundo é o
domínio do software. Nós devemos compreender do começo que o software está originado e
relacionado profundamente a este domínio.

O software é composto do código. Nós podemos ser tentados a gastar demasiado tempo e
muita hora com o código, e vê o software como simplesmente objetos e métodos.

Considere a fabricação de um carro em tempos passados. Os trabalhadores envolvidos na

fabricação podem especializar-se em produzir as peças do carro, mas estes trabalhadores
frequentemente tem uma vista limitada do processo de fabricação do carro. Ao final da
fabricação eles verão o carro porque uma coleção enorme de peças começaram a se
encaixar, mas a frabricação do carro é muito mais que simples encaixes.

Bons Começos para a frabicação de um carro em tempos atuais. Começa com extrema
atenção quando se escreve as especificações. O mesmo continua para o design. Meses,
talvez anos do tempo gastados em design, mudando e refinando para alcançar a perfeição,
até refletir a visão original. O processo de design não está só em papel. Muita dele inclui
fazer modelos do carro, e testá-los sob determinadas circunstâncias para ver se funcionam.
O design pode ser modificado baseado nos resultados dos teste. O carro é emitido à
produção eventualmente, e as peças são criadas e montadas junto.

O desenvolvimento do software é similar. Nós não podemos apenas sentar e datilografar o

código, mesmo sendo um especialista em programação.

A fim de criar um software bom, você tem que saber o que esse software é como um todo.
Você não pode criar um software de operação bancária a menos que você tenha uma
compreensão clara do é uma operação bancária como um todo, é seu dever compreender o
domínio da operação bancária.

É possível criar um software de operação bancária complexo sem o pleno conhecimento do

domínio? Nunca. Quem sabe o caixa do banco? arquiteto do software? Não. O analista do
software? Não realmente. O analista sabe analisar um tópico dado, quando é dado todos os
ingredientes necessários. O desenvolvedor? Esquece. Quem então? Os banqueiros, é obvio.
O sistema de operação bancária é bem compreendido pelos responsáveis e por seus
specialistas. Eles sabem todos os detalhes. Este é o lugar onde nós devemos sempre
começar: o domínio

Quando nós começamos um projeto de software, nós devemos focalizar no domínio que se
esteja operando. A finalidade inteira do software é realçar um domínio específico. Fazendo
isso, o software tem que caber harmoniosamente com o domínio que foi criado. O contrário
introduzirá em tensão do domínio, no mau funcionamento provocando danos, e até mesmo
no caos.

Alguém sem conhecimento da operação bancária deve aprende muito apenas lendo o código
em um modelo do domínio. Isto é essencial. O software que não tem suas raizes plantadas
profundamente no domínio não reagirá bem à mudança sobre o tempo.

Assim nós começamos com o domínio. Então como? Um domínio é algo deste mundo. Não
pode apenas ser feito sobre o teclado no computador para transformar-se em código. Nós
necessitamos criar um abstraction do domínio. Nós aprendemos muito sobre um domínio ao
falar com os peritos do domínio. Mas este conhecimento não será facilmente introduzido
como código na construções do software, a menos que nós construirmos uma abstração
dele, uma visão em nossas mentes deve ser criado. No começo, essa visão sempre será
incompleta. Mas com o tempo, trabalhando nele, nós fazemos ele melhor, e assim ele
torna-se mais e mais claro para nós. O que é este abstraction ? É um modelo, um modelo
do domínio. De acordo com Eric Evans, um modelo do domínio não é um diagrama
particular; é a idéia a que o diagrama é pretendido fazer saber. Não é justo o conhecimento
na cabeça de um perito do domínio; é uma rigorosa organização e seleção desse
conhecimento.

O modelo é nossa respresentação interna do domínio, e é muito necessário durante todo o

projeto e o processo do desenvolvimento. Durante o processo do projeto nós recordamos e
fazemos consultas as referências ao modelo.

Mesmo um domínio específico poderiam ser mais do que uma mente humana pode aguentar
de uma so vez. Nós precisamos organizar a informação, dividir a parte macro em partes
menores, para agrupar aquelas partes nos módulos lógicos, e fazer testes de cada
componente um de cada vez. Nós necessitamos deixar para fora algumas partes do
domínio. Um domínio contem apenas informação para inclui-lo no modelo. E muito dele não
é mesmo necessário para ser considerado. Este é o desafio. O que eu devo manter e o que
eu devo jogar fora? Esta é a função do design, o processo da criação do software. O
software de operação bancária certamente contem o endereço do cliente, mas não deve
importar-se com a cor do olho do cliente. Este é um caso óbvio, mas outros exemplos não
serão óbvios.

Um modelo é uma parte essencial do design do software. Nós necessitamos tratar da

complexidade. Todo nosso processo de pensamento sobre o domínio sintetizado dentro
deste modelo. Isso é bom, mas tem que sair de nossa cabeça. Nós necessitamos comunicar
este modelo com os peritos do domínio, com os designers, e com os developers. O modelo é
a essência do software, mas nós necessitamos criar maneiras expressá-lo, para comunicá-lo
com o outro. Nós não estamos sozinhos neste processo, assim que nós necessitamos
compartilhar do conhecimento e da informação, e nós necessitamos fazê-la bem,
precisamente e sem ambigüidade.

Existem muitas maneiras diferentes de fazer isso. Um gráfico: diagramas, casos de uso,
desenhos, figuras, escrevendo. Outro é a língua. Nós podemos e devemos criar uma
línguagem de comunicação sobre detalhes do domínio. Nós detalharemos todo o estes mais
tarde, mas o ponto principal é que nós necessitamos comunicar o modelo.

Quando nós temos um modelo expressado, nós podemos começar fazer o design do codigo.
Isto é diferente do design do software. Design do software é como criar a arquitetura de
uma casa.Na outra mão, o design do código está trabalhando nos detalhes, como a posição
de uma pintura em uma determinada parede. O design do código é também muito
importante, mas não mais importante que os fundamentos do design do software. Um erro
do design do código geralmente é corrigido mais facilmente, os erros do design do software
são muito mais caros de reparar. Uma coisa é mover a pintura para a esquerda, e outra
coisa completamente diferente mover a casa de lugar.

Mas no final o produto não será bom se o design do código não for bom. Aqui os patterns do
design do codigo deverão ser apresentados, e devem ser aplicados quando necessários. As
boas técnicas de programação irão ajudam a criar um código limpo.

Há diferentes abordagens para o design do software. Um é o waterfall design method. Este

método envolve um número de estágios. Os peritos do negócio expõem as exigências mais
importantes que são comunicadas aos analistas do negócio. Os analistas críam um modelo
baseado nessas exigências, e passam os resultados aos desenvolvedores, que começam a
codificar baseado em o que receberam. É um fluxo de sentido único do conhecimento. Esta
é uma abordagem tradicional no design do software, e foi usada com um determinado nível
de sucesso sobre os anos, tem seus falhas e limites. O problema principal é que não há
nenhum retorno dos analistas aos peritos do negócio ou dos desenvolvedores aos analistas.

Uma outra abordagem é a Agile methodologies, tais como a Extreme Programming (XP).
Estas metodologias são movimentos coletivos contra à aborgadem da waterfall, isso é
resultando das dificuldades de tentar vir a expor as exigências do projeto dentro da equipe.

É realmente dificil criar um modelo completo que cubra todos os aspectos das exigencias
mais importantes do domínio. Isto exige muita averiguação, e frequentemente você apenas
não pode ver todas as exigencia envolvidas no começo, nem pode prever alguns dos efeitos
laterais ou dos erros negativos de seu design. Outro problema que precisa ser resolvido é
conhecido tambem como "analysis paralysis", os membros da equipe ficam receosos em
tomar algumas decisões sobre o projeto como um todo. Eles reconhecem a importancia do
design e temem expor as exigencia erradas. Empregar um grande ideal de implementação
com flexibilidade, com o desenvolvimento iterativo, participação da parte interessada do
negócio e muitas refatorações contínuas, a equipe do desenvolvimento começa aprender
mais sobre o domínio do cliente e pode melhorar o software do produto que se encontra
com as necessidades dos clientes.

Os métodos ágeis têm seus próprios problemas e limitações; eles protegem a simplicidade,
mas todos tem sua própria visão do que esta acontecendo. Veja bem, refatoração contínua
feita pelos desenvolvedores sem princípios solidos de design irá produzir códigos que é são
dificies de compreender ou mudar. Por outro lado a abordagem da waterfall poder conduzir
ao overengineering, o medo do overengineering pode conduzir a um outro medo: o medo
de fazer um design completamente fora do escopo e refazer tudo novamente.

Este "livro" apresenta os princípios do domain driven design(projeto dirigido por domínio,
DDD), que quando aplicado pode aumentar muito a abilidade dos processos de
desenvolvimento para modelar e implementar os problemas complexos em um dominio
reutilizavel. O DDD combina a prática e desenvolvimento e design, e mostras como o design
e o desenvolvimento podem trabalhar junto para criar uma solução melhor. Um bom design
acelera o desenvolvimento.

Building Domain Knowledge

Vamos considerar o exemplo de um projeto para um sistema de controle do vôo, e como o
conhecimento do domínio pode ser construído.
Milhares de aviões estão no ar sobreveando todo o planeta planeta. Estão voando seus
próprios trajetos para seus devidos destinos, e é muito importantes certificar-se que não
colidem no ar. Nós não tentaremos elaborar um sistema inteiro de controle do tráfego, mas
em um subconjunto menor que seja um sistema de monitoração do vôo. O projeto proposto
é um sistema de monitoração de trilhas de cada vôo sobre alguma área, determina se o vôo
esta seguindo sua rota suposta ou não, e se existe a possibilidade de uma colisão.

Quando será que vamos começar a ter uma perspectiva de desenvolvimento do software ?
Na secção anterior dissemos que devemos começar por compreender o domínio, que neste
caso, é o monitoramento do tráfego aéreo. controladores de tráfego aéreo são os
especialistas desta área. Mas os controladores não são designs do sistema ou specialistas do
software. Você não pode esperá que eles vao lhe entregar uma descrição completa do
domínio de seu problema.

Os controladores de tráfego de aéreop possum um vasto conhecimento sobre seu domínio,

mas para contruir um modelo será necessário extrair as informações essenciais e centraliza-
la. Quando você começar a falar com eles, você vai ouvir muito sobre os aviões que
decolam, aterrisam, os perigo de colisão, os aviões que estão esperando a autorização de
pouso, e etc. Para encontrar ordem nesta aparentemente quantidade caótica de informação,
temos que começar de algum lugar.

O controlador e você concordam que cada avião tem uma partida e um aeroporto de
destino. Sendo assim nós temos um avião, uma partida e um destino, como mostrado na
figura abaixo

Enfim, o avião sai de algum lugar e chega em outro. Mas o que acontece no ar? Qual o
trajeto do vôo? Realmente nós estamos mais interessados no que acontece durante o vôo.
O controlador diz que avião será atribuído um plano do vôo que seja suposta deve
descrever o curso inteiro do avião. Enquanto você aguardava sobre a definição de um plano
de vôo, você imaginou qual o caminho seguido pelo avião enquanto ele esta no ar. Após
uma discussão mais aprofundada, você ouve uma palavra interessante: rota. Ela
instantaneamente captura sua atenção, e por uma boa razão. A rota contem um conceito
importante sobre o curso do avião.O que os aviões fazem durante o vôo, eles seguem uma
rota. É óbvio que os pontos de partida e os de destino do avião são também os pontos que
começam e de terminam a rota. Assim, em vez de associar a aeronave a pontos de partida
e destino, parece mais natural associá-la com uma rota, que seja associada por sua vez
com a partida e o destino correspondentes.

Falando com o controlador sobre as rotas que os aviões seguirão, você descobriu que
realmente a rota é composto por pequenos segmentos, que juntos constituem uma espécie
de uma linha torta desde a partida com o seu destino. A linha é suposto de passar por pré-
determinados pontos fixos. Assim, uma rota pode ser considerada uma série de pontos
consecutivos. Neste momento você já não vê a partida e o destino como pontos terminais
da rota, mas apenas outros dois pontos entre outros existentes. Isto é provavelmente
completamente diferente de como o controlador os vê, mas é um abstraction necessária
para ajudar mais tarde. As mudanças resultantes baseadas nestas descobertas são

O diagrama mostra um outro elemento, o fato que cada ponto é um reparo no mapa
seguido pela rota, e é expressado como um mapa tridimensional. Mas quando você falar ao
controlador, você descobrirá que não ele vê dessa maneira. Realmente vê a rota como a
projeção na terra do plano de vôo. Os pontos são ajustes na superfície do trajeto
determinado excepcionalmente por suas latitude e longitude. Assim o diagrama correto é:

Que está acontecendo realmente aqui? Você e os peritos do domínio estão falando, vocês
estão trocando conhecimentos. Você começa fazer perguntas, e eles respondem. Enquanto
fazem isso, os conceitos essenciais do dominio do tráfego de aéreo estão sendo definidos.
Esses conceitos podem sair desorganizado, mas ainda assim são essenciais para
compreender o domínio. Você e os peritos do dominio precisam aprender o máximo possível
sobre o domínio do controle de trafego aereo. E fazendo as perguntas certas, processando a
informação de maneira correta, em você e os peritos começarão esboçar uma visão do
domínio, um modelo do domínio. Esta visão está incompleta e não revisionada, mas é o
começo que você precisa. Tente entender os conceitos essenciais do domínio.

Esta é uma parte importante do design. Geralmente há umas discussões longas entre
arquitetos do software ou desenvolvedores e os peritos do domínio. Os especialistas do
software querem extrair o conhecimento dos peritos do domínio, e também têm que
transformá-lo em uma forma útil. Em algum momento, eles desejam criar um primeiro
protótipo para ver como funciona até hoje. Ao fazê-lo podemos encontrar algumas questões
com os seus modelos, ou sua abordagem, e podem querer mudar o modelo. Uma
comunicação é não somente de sentido único, dos peritos do domínio aos arquiteto do
software e ainda mais para os desenvolvedores. Há também um retorno de informação, que
ajuda a criar uma modelo melhor, e tornar mais clara compreensão do domínio. Os peritos
do domínio sabem sua área de perícia, mas as organizam e usam o conhecimento de uma
maneira específica, que não é sempre a melhor a ser executado em um software. A mente
analítica dos designes e desenvolvedores do software contribui para alguns dos conceitos
chaves da "Aircraft Route * Fix 2DPoint" do domínio durante discussões com peritos do
domínio, e ajuda também construir uma estrutura para as discussões futuras porque nós
veremos no capítulo seguinte. Nós, specialists do software (arquitetos do software e os
desenvolvedores) e os peritos do domínio, estamos criando o modelo do domínio juntos, e o
modelo é o lugar onde essas duas áreas de competência reunir-se. Isto parece como um
processo muito moroso, e é, mas este é como deve ser, porque a finalidade na extremidade
do software é resolver problemas de negócio em um domínio real da vida, por isso, a
informação dominio do software tem de ser sincronizada com o dominio real.

The Need for a Common Language

O capítulo anterior descreveu que é absolutamente necessário desenvolver um modelo do
domínio tendo o trabalho dos specialists do software com os peritos do domínio; entretanto,
essa aproximação tem geralmente algumas dificuldades iniciais devido a uma barreira
fundamental de uma comunicação. Os desenvolvedores têm em suas mentes uma visão das
classes, métodos, algoritmos, testes padrões, e eles tendem sempre a fazer uma mistura
entre conceito da vida e os conceitos de programação. Querem ver um montante de classes
para criar uma relação do modelo e eles. Eles pensam nos termos herança, polimorfismo,
OOP, etc. Eles conversam como todo um time faria. E é normal para eles fazer assim.
Desenvolvedores serão desenvolvedores. Mas os peritos do domínio não sabem geralmente
nada sobre desenvolvimento. Não têm nenhuma idéia sobre bibliotecas de software,
frameworks, persistence, em muitos casos nem sequer que bases de dados existe. Eles
sabem sobre sua área de perícia específica.

No exemplo de monitoração de tráfego aéreo, os peritos do domínio sabem sobre planos,

sobre rotas, alturas, longitudes e latitudes, eles sabem sobre o exercício de itinerário
normal, sobre a trajetoria dos aviões. E fala-se na sua própria gíria, que por vezes não é tão
fácil de seguir por um outro lado.

Para superar esta diferença no estilo de uma comunicação, quando nós construímos o
modelo, nós devemos comunicar-se para trocar aproximadamente idéias o modelo, sobre os
elementos envolvidos no modelo, como nós lidamos com o modelo, o que é relevante e o
que não é. Comunicação neste nível é primordial para o êxito do projeto. Se um disser algo,
e o outro não compreender ou, pior ainda, que entenda de outra coisa, quais são as
hipóteses para que o projecto sejam bem sucedidos?

Um projeto enfrenta problemas sérios quando os membros da equipe não compartilham de

uma língua comum para discutir o domínio. Os peritos do domínio usam seu jargão quando
os membros técnicos da equipe tiverem sua própria língua ajustada discutindo o domínio
nos termos do design.

A terminologia utilizada no dia-a-dia das discussões é desconectada da terminologia

encaixada no código (afinal de contas o produto mais importante é o software do projeto). E
mesmo assim a mesma pessoa usa uma língua diferente no discurso e outra na escrita, de
modo que a formar incisivas expressões do domínio muitas vezes transientes saindo de uma
forma que nunca é capturado em código, ou mesmo por escrito.

Durante essas sessões de comunicação, a tradução é muitas vezes utilizadas para deixar os
outros compreender o que alguns conceitos estão abordando. Os desenvolvedores poderiam
tentar explicar alguns design patterns utilizando termos incompreensiveis, e às vezes sem
sucesso. Os peritos do domínio podem suas idéias criando um jargão novo. Durante este
processo uma comunicação é falha, e este tipo da tradução não ajuda ao processo de
construção do conhecimento.

Temos a tendência de utilizar a nossa própria linguagem durante estas sessões concedidas,
mas nenhuma destas linguas pode ser uma linguagem comum porque nenhuma atende a
todas as necessidades.

Nós necessitamos definitivamente falar a mesma língua quando nós nos encontramos com
para falar e definir o modelo. Que língua é esta então? Língua dos desenvolvedores? Língua
dos peritos do domínio? Algo entre as duas?

Um princípio fundamental do DDD é usar uma língua baseada no modelo. Desde que o
modelo é um terreno comum, o lugar onde o software se encontra com o domínio, que é
adequado para a utilização de contrução da linguagem do dominio.

Usar o modelo como a espinha dorsal de uma língua. Pedindo para que a equipe use essa
língua consistentemente em todas as comunicações, e também no código. Enquanto
compatilhamos conhecimento e resolvemos o modelo, a equipe usa esse dialeto para a
escrrver os diagramas. Garanta que a linguagem seja consistentemente usada em todas as
formas de comunicação utilizadas pela equipe; por esta razão, a linguagem é denominado
ubiquidade língua.

A língua Ambiqua conecta todas as partes do projeto, e cría a premissa para que a equipe
de projeto funcione bem. Ela demora semanas ou meses para tomar forma em um projeto
de grande escala. Os membros da equipe descobrem que alguns dos conceitos iniciais eram
eram incorrectos ou mal utilizados, ou descobrem novos elementos do projeto que
necessitam ser considerados e enquadrar-se na concepção global. Tudo isso não é possível
sem uma linguagem comum.

Uma lingua comum não aparecem do dia para a noite. É um trabalho duro e que exige
muito foco para certificar-se de que os elementos chaves da língua estão trazidos a
percepção de todos. Nós necessitamos encontrar aqueles conceitos chaves que definem o
domínio do projeto, e devemos encontrar as palavras correspondentes para os termos do
dominio, e começar a usá-las. Alguns destes são facilmente identificados, mas alguns são
mais dificeis.
Iron para fora dificuldades experimentando com as expressões alternativas, que refletem
modelos alternativos. Então refactor o código, rebatizando classes, métodos, e módulos
para conformar-se ao modelo novo. Resolver a confusão sobre termos na conversação,
apenas na maneira que nós vimos concordar com o meaning de palavras ordinárias.

A construção de uma língua comum tem um resultado claro: o modelo e a língua estão
fortemente interligados entre si. Uma mudança na língua deveria tornar-se em uma
mudança do modelo.

Os peritos do domínio devem opinar aos termos ou às estruturas que são inábeis ou
inadequadas para à compreensão do domínio. Se os peritos do domínio não puderem
compreender algo no modelo ou na língua, então é mais provável que algo está errado com
o dominio. Por outro lado, os desenvolvedores devem prestar atenção para a ambigüidade
ou a inconsistência que tenderá a surgir no design

MODEL-DRIVEN DESIGN (DDD)

Os capítulos anteriores salientou a importância de uma aproximação ao desenvolvimento do
software que é centrado no domínio do negócio. Dissemos que é fundamental a importancia
de criar um modelo que esta profundamente enraizado no domínio, e refletir os conceitos
essenciais do domínio com grande precisão. A língua comum deve ser plenamente exercida
durante todo o processo, a fim de facilitar a comunicação entre os specialists do software e
os peritos do domínio, e descobrir os conceitos chaves do domínio que devem ser usados no
modelo. A finalidade deste processo é criar um modelo bom. A etapa seguinte é
implementar o modelo no código. Isto processo é igualmente importante para o
desenvolvimento do software. Ter criado um grande modelo, mas não transferi-lo
corretamente no código acabará criando software da qualidade questionável.

Acontece que os analistas do software trabalham com os peritos do domínio do negócio

durante meses, descobrem os elementos fundamentais do domínio, enfatizam os
relacionamentos entre eles, e cría um modelo correto, que capta com precisão o domínio.
Então, o modelo é transferido para os desenvolvedores de softwares. Os desenvolvedores
puderam olhar o modelo e descobrir que alguns dos conceitos ou dos relacionamentos
encontrados neles não podem corretamente ser expressados no código.

Assim usam o modelo como a fonte original da inspiração, mas eles críam seu próprio
design que obtém algumas idéias do modelo, e adiciona alguma do seus próprios. O
desenvolvimento o processo continua mais longe, e mais classes são adicionadas ao código,
expandindo dividindo-se entre o modelo original e a implementação definitiva. Um resultado
final bom não é assegurado. Bom desenvolvedores poderiam entregar um produto que
funcione, mas será que vai defender os julgamentos de tempo? Será que vai ser facilmente
extendido? Será facil de dar manutenção?

Qualquer domínio pode ser expressado com muitos modelos, e qualquer modelo pode ser
expressado em várias maneiras no código. Para cada problema particular pode haver mais
do que uma solução. Qual escolha fazer? Ter um modelo analìticamente correto não
significa que o modelo pode diretamente ser expressado no código.

Ou talvez a sua execução quebrará alguns princípios do design do software, que não é
aconselhável. É importante escolher um modelo que possa ser fàcilmente e exatamente
extraido para o código. Como fazer a abordagem e a transição do modelo para o código?
Uma das técnicas de design recomendadas é chamado de analysis model, que é visto
separado do design do código e geralmente usado por pessoas diferentes. O modelo da
análise é o resultado da análise do domínio do negócio, resultando um modelo que não
tenha consideração para o software utilizado para a execução. Tal modelo é usado para
compreender o domínio. Um determinado nível de conhecimento é construído, e o resultado
do modelo pode ser analìticamente correto. O software não é levado em consideração nesta
fase, uma vez que é considerado ser um fator confuso. Este modelo atinge os
desenvolvedores que estão destinados a compreender e fazer o design. Uma vez que o
modelo não foi construído com princípios de design em mente, ele provavelmente não
servirá muito bem a essa finalidade. Os desenvolvedores terão que adaptá-la, ou criar um
design separado. E não é facil fazer essa adaptação entre o design e o código. O resultado é
que os modelos da análise são abandonados logo depois que a codificação começa.

Uma das principais questões com esta abordagem é que os analistas não podem prever
alguns dos defeitos em seu modelo, e todos as complexidades do domínio. Os analistas
podem ter entrado em detalhes com alguns componentes do modelo, e não detalharam
bastante outro. Os detalhes muito importantes são descobertos durante o processo de
design e o processo de execução. Um modelo que seja indigno ao domínio pode vir a ter
problemas sérios com os objeto de persistencia, ou comportamento inaceitável de
desempenho

Os desenvolvedores serão obrigados a tomar as decisões próprias, e fará mudanças no

design a fim resolver um problema real que não foi considerado quando o modelo foi criado.
Eles criam um design afastado do modelo, o que torna menos relevante.

Se os analistas trabalharem independentemente, criarão eventualmente um modelo.

Quando este modelo é passado aos designers, alguns conhecimento dos analistas sobre o
domínio e o modelo é perdido. Enquando o modelo pôde ser expressado nos diagramas e na
escrita, As mudanças dos designers que definirão o sentido inteiro do modelo, ou os
relacionamentos entre alguns objetos, ou seu comportamento. Existem detalhes em um
modelo que não são expressados fàcilmente em um diagrama, e não pode inteiramente ser
apresentado sequer por escrito. Os desenvolvedores passão por momentos complicados
para esboçar isso. Em alguns casos farão algumas suposições sobre o comportamento
pretendido, e é possível tais suposições estejam erradas, resultando em um funcionamento
incorreto do programa.

Os analistas têm suas próprias reuniões fechadas onde muitas coisas são discutidas sobre o
domínio, e há um grande conhecimento sendo compartilhado. Eles críam um modelo que
supostamente contem toda a informação necessária de uma forma condensada, e os
desenvolvedores têm que assimilar tudo lendo os documentos originais que lhes foram
passado. Seria muito mais produtivo se os desenvolvedores pudessem se juntar as reuniões
dos analista e assim alcançar uma vista desobstruída e completa do domínio e do modelo
antes de começarem projetar o código.

Uma melhor abordagem é estreitar a relação modelagem do domínio e design. O modelo

deve ser construído com um olho aberto às considerações do desidn do software. Os
desenvolvedores devem ser incluídos no processo de modelagem. A idéia principal é
escolher um modelo que possa apropriadamente ser expressado no software, de modo que
o processo do design seja direto e baseado no modelo. Firmemente relacionar o código de
um modelo subjacente dá o signigicado do código e torna o modelo relevante.

Pegar os desenvolvedores envolvidos fornece um retorno. Isto cria um modelo correto para
ser implementado no software. Se existe algo errado, é identificado em um estágio
adiantado, e o problema pode fàcilmente ser corrigido.

Aqueles que escrevem o código devem conhecer o modelo muito bem, e se sentem
responsáveis pela sua integridade. Deviam compreender que a alteração do código implica
uma mudança para o modelo; entretanto ele vão refatorar o codigo ao ponto que não
expressa mais o modelo original. Se o analista for separado do processo da execução, ele
perderá logo o conceito sobre as limitações introduzidas pelos desenvolvedores. O resultado
é um modelo que não seja prático.

Toda a pessoa técnica que contribui ao modelo deve gastar algum tempo para olhar o
código, qualquer que seja o papel primordial que ele ou ela desempenham sobre o projecto.
Alguém responsável por mudar o código deve aprender a se expressar no modelo do código.
Cada colaborador deve ser envolvido em algum nível da discussão sobre o modelo e ter o
contato com peritos do domínio. Aqueles que contribuem de maneiras diferentes devem
conscientemente notar aqueles que fazem o código em uma troca dinâmica das idéias do
modelo através da línguagem ambigua.

Se o design, ou alguma parte central dele, não traçarem ao modelo do domínio, que o
modelo é de pouco valor, a exatidão do software então é suspeito. Ao mesmo tempo,
complexos mapeamentos entre modelos e funções do design são difíceis de compreender e,
na prática, impossível manter o design sem mudanças. O ideal é divide-se entre a análise e
design de modo que que a perspicácia adquirida em cada uma dessas atividades não
prejudique a outros.

Projetar uma parcela do design do sistema de software e refletir o modelo do domínio é

uma maneira, de modo que a transição seja óbvia. Revisitar o modelo e modificá-lo a ser
executado mais naturalmente no software, mesmo enquanto você procura refletir uma
introspecção mais profunda no domínio. Procurar um único modelo que sirva as ambas
finalidades, além de suportar uma língua ambigua comumente usada entre os participantes.

Extrair do modelo a terminologia utilizada no design e a atribuição de responsabilidades. O

código se torne uma expressão do modelo, de modo que a modificação do código pode ser
uma mudança do modelo. O seu efeito deve flutuações através do resto do projecto.

Amarrar firmemente a execução a um modelo requer geralmente as ferramentas e as

languages de desenvolvimento de software que suportam um paradigm modelando, tal
como programação orientada a objeto.

A programação orientada a objeto é apropriada para o modelo de execução porque ambos

são baseados no mesmo paradigm. A programação orientada a objetos fornece classes dos
objetos e associações das classes, dos exemplos do objeto, e da relação entre eles. As
línguas de OOP fazem a possíveis criar mapeamentos diretos entre os objetos modelo com
seus relacionamentos, e suas contrapartes de programação.

The Building Blocks Of A Model-Driven Design

As seguintes seções deste capítulo apresentarão o mais importante dos pattern a ser usado
no DDD. A finalidade destes testes patterns é apresentar alguns dos elementos chaves de
modelagem de objetos e design software do ponto de vista do DDD. O seguinte diagrama é
um mapa dos patterns apresentados e dos relacionamentos entre eles.
Quando nós criamos uma aplicação do software, uma parte grande da aplicação não está
relacionada diretamente ao domínio, mas é parte da infraestrutura ou serve ao próprio
software. Isto é possível e aprovado para uma parte do domínio de uma aplicação para ser
completamente pequeno comparado ao restante, desde que a típica aplicação contenha as
dezenas de código relacionados ao acesso ao base de dados, ao arquivo ou acesso da rede,
interfaces com o usuario e etc.

Em um programa orientado a objeto, UI, base de dados, e outros código da sustentação,

são desenvolvidos frequentemente direto nos objetos do negócio. A lógica adicional do
negócio é encaixada no comportamento de interfaces e de acesso a base de dados. Isto as
vezes acontecem porque é a maneira mais fácil de fazer o sistema rapidamente.

Entretanto, quando ao código do domínio relacionado é misturado com as outras camadas,

dessa forma torna-se extremamente difícil de ver e pensar no codigo orientado a objetos.
As mudanças Superficial na interface podem realmente mudar a lógica do negócio. Mudar
uma regra de negócio pode alterar a interface, ou o código da base de dados, ou outros
elementos do programa. Implementar incoerencia no codigo, torna o uso do DDD
impraticavel. O programa deve ser mantido muito simples ou torna-se impossível
compreender com todas as tecnologias e lógica envolvidas na interface do usuario junto
com as logicas do dominio.

É necessário um complexo particionamento do programa em camadas. Desenvolver uma

concepção dentro de cada camada que é coerente e que depende apenas das camadas
inferiores. seguir padrões arquitectónico padrão para fornecer um engate avulso para as
camadas acima. Concentrar todo o código relacionado ao modelo do domínio em uma
camada e isolá-lo da relação de usuário, da aplicação, e do código da infraestrutura.
Objetos de domínio, sem resposabilidade de se mostrar, armazenando neles mesmos,
administrando tarefas de aplicativos e assim por diante, podem estar focados em expressar
o modelo do domínio. Isso permite o modelo envolvido ser rico e claro o bastante para
capturar a essencia do conhecimento do negócio e colocoar isso para trabalhar

A solução para uma arquitetura comum para DDD contem quatro camadas essenciais

User Interface (Presentation Layer):

Responsável por apresentar a informação ao usuário e interpretar os comandos do usuário

Application Layer:
Esta é uma fina camada que coordena a atividade da aplicação. Não contem a lógica de
negócio. Não segura o estado dos objetos de negócio, mas pode segurar o estado do
progresso de uma tarefa da aplicação.

Domain Layer
Esta camada contem a informação sobre o domínio. Este é o coração do negócio do
software. O estado de objetos do negócio é prendido aqui. A persistencia dos objetos do
negócio e possivelmente seu estado é delegado à camada da infraestrutura.

Infrastructure Layer
Esta camada age como uma biblioteca de suporte para todas as outras camadas. Ela
fornece uma comunicação entre as camadas, adiciona persistencia objetos de negócio,
contem bibliotecas de suportande para a camada de interação com o usuario, e etc.

É importante dividir uma aplicação em camadas separadas, e estabelecer regras de

interações entre elas. Se o código não for separado claramente em camadas, ficará muito
dificil fazer ou controlar as mudanças. Uma simples mudança em uma seção do código pode
gerar resultados inesperado e indesejáveis em outras seções. A camada do domínio deve
ser focalizada no nucleo das tarefas do domínio. Não deve ser envolvida em atividades da
infraestrutura. A interface com o usuario nao deve ser firmemente conectado à lógica do
negócio, nem às tarefas que pertencer normalmente à camada de infraestrutura. Uma
camada de aplicação é necessário em muitos casos. Tem que haver um gerente sobre a
lógica do negócio que supervisiona e coordena a atividade total da aplicação.

Um exemplo típico de interação da aplicação, domínio e infraestrutura podiam funcionar

dessa forma: O usuário deseja um livro de rotas de vôos, e pergunta ao serviço da
aplicação na camada de aplicação como fazer isso. Um parte da aplicação busca os objetos
relevantes do domínio da infraestrutura e invoca métodos relevantes para fazer isso, por
exemplo: para verificar margens da segurança a outros vôos já registrados. Uma vez que os
objetos do domínio fizeram todas as verificações e atualizaram seu status para “decidido”, o
serviço da aplicação persiste os objetos para a infraestrutura.