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.