Domain driven design in a nutshell

Editor's Notes

• #2: ESCREVER O SOFTWARE É FÁCIL, DESCULPE POR ESCREVER GREENFIELD SOFTWARES É FÁCIL. DESENVOLVIMENTO DE SOFTWARE É UM CRIATIVO E PROCESSO ADAPTATIVO. QUANDO SE TRATA DE MODIFICAR CÓDIGO ESCRITO POR OUTROS DESENVOLVEDORES OU CÓDIGO QUE VOCÊ ESCREVEU HÁ SEIS MESES, PODE SER UM POUCO CHATO NO MELHOR DOS CASOS E NO PIOR UM PESADELO. O SOFTWARE FUNCIONA MAS VOCÊ NÃO CERTEZA EXATAMENTE COMO. ELE CONTÉM TODOS OS QUADROS DIREITA, PADRÕES E FOI CRIADO USANDO UMA ABORDAGEM ÁGIL, AINDA INTRODUZINDO NOVOS RECURSOS NA BASE DE CÓDIGO É MAIS DIFÍCIL DO QUE DEVERIA SER. MESMO OS ESPECIALISTAS DE NEGÓCIOS SÃO DE NENHUM USO QUE O CÓDIGO NÃO TEM QUALQUER SEMELHANÇA COM A LINGUAGEM QUE ELES USAM. TRABALHO EM TAIS SISTEMAS SE TORNA UMA TAREFA DEIXANDO COLABORADORES FRUSTRADOS E DESPROVIDOS DE QUAISQUER PRAZER CODIFICAÇÃO. ANTES QUE VOCÊ POSSA DESENVOLVER UMA SOLUÇÃO, VOCÊ DEVE ENTENDER O PROBLEMA. A NECESSIDADE DA EQUIPE DE DESENVOLVIMENTO PARA VALOR DOMÍNIO DE CONHECIMENTO, TANTO COMO CONHECIMENTOS TÉCNICOS ESPECIALIZADOS SÃO VITAL TER UMA VISÃO MAIS PROFUNDA DO DOMÍNIO DO PROBLEMA. PARTES CENTRAIS DO SEU PRODUTO QUE SÃO SUFICIENTEMENTE COMPLEXAS OU FREQÜENTEMENTE MUDANÇA DEVE SER BASEADA EM UM MODELO. UM MODELO QUE ESTÁ EM SINERGIA COM O DOMÍNIO DO PROBLEMA PERMITIRÁ QUE O SEU SOFTWARE A SER ADAPTÁVEL E COMPREENDIDO POR OUTROS DESENVOLVEDORES E ESPECIALISTAS EM NEGÓCIOS.
• #3: Um domínio de problema se refere à área disciplinar para a qual você estiver construindo SOFTWARE. Peritos no dominio do PROBLEMA trabalham em conjunto com a equipe de desenvolvimento para se concentrar nas áreas do domínio que sejam úteis para ser capaz de produzir software valioso. Por exemplo, quando a escrita de software PARA A INDÚSTRIA DE SAÚDE PARA GRAVAR o tratamento do paciente, NÃO É importante aprender a se tornar um médico. O que é importante entender é a terminologia da indústria da saúde, como os departamentos de vista diferentes pacientes e
• #4: O DESIGN É ALGO QUE DEVE SER PENSADO, REFLETIDO E REMOLDADO, PARA QUE FINALMENTE ELE TENHA UMA PERFEITA ADEQUAÇÃO E FORNEÇA UMA SOLUÇÃO VIÁVEL AO QUE VOCÊ DESEJA. Domain-Driven Design (DDD) é uma filosofia de desenvolvimento definida POR ERIC EVANS EM SEU Domain-Driven Design obra seminal: LUTAR CONTRA COMPLEXIDADE NO CORAÇÃO DE SOFTWARE (Addison-Wesley Professional, 2003). DDD é uma abordagem de desenvolvimento de software projetada para GERIR complexo e GRANDE ESCALA produtos de software. No seu coração Centra-se na criação de uma linguagem COMPARTILHADA conhecido como a linguagem ubíqua forma eficiente e eficaz descrever um domínio de problema
• #5: É algo impacto que permite uma maior compreensão do domínio do problema (para o negócio e a equipe de desenvolvimento) e uma comunicação mais eficaz. Estes valores-chave têm um enorme sobre projetos que eles colocam muito maior importância na análise e compreensão sobre estruturas técnicas e metodologias, o que acaba por fazer produtos de software bem sucedida.
• #6: A Focus On Collaboration A Focus On Language A Focus On Building A Model For Core Domains A Focus On Context A Focus On Organization Em sintese o DDD aborda a resolucao de problemas do mapeamento de projetos de software para um domínio não trivial você deve primeiro entender as dificuldades de criar e manter software. De longe, o padrão de design mais popular software de arquitetura para aplicações de negócios é o Big Ball of Mud (BBoM) padrão. BBoM, tal como definido por Brian Foote e Joseph Yoder.
• #7: A falta de foco em uma linguagem comum e conhecimento dos resultados domínio do problema em uma base de código que funciona, mas não revela a intenção do negócio. Isso faz com que bases de código muito difícil ler e manter como traduções entre o modelo de análise e linguagem de negócios para o código implementação e conceitos técnicos podem ser caros. Código sem uma ligação a um modelo de análise que a empresa entende rapidamente em conformidade com a BBoM padrão o que significa que nenhum insight domínio pode, eventualmente, ser descoberto pela equipe de desenvolvimento como base código é focada conceitos negócio não entende
• #9: Continuando a persistir com um padrão de espaguete-como arquitetura pode levar a um ritmo lento de aprimoramento do recurso. Quando novas versões do produto são lançados, muitas vezes eles podem ser buggy devido à confusão ininteligível da base de código que os desenvolvedores tem que lidar com eles. Com o tempo, a equipe de desenvolvimento cada vez mais queixas sobre a dificuldade de trabalhar em uma bagunça. embora recurso é adicionado ao projeto, a velocidade não pode ser aumentado para um nível que satisfaça os negócios. No final, agravada pela situação, o pedido de reescrever a aplicação temida é concedido. Sem o devido cuidado e consideração, no entanto, mesmo o projeto greenfield pode cair aves do mesmo questões que criaram o BBoM originais. Essa experiência toda pode ser frustrante para o negócio que viu um grande retorno sobre o investimento em termos de recursos e velocidade de entrega no início, mas ao longo do tempo, mesmo com i investimento adicional
• #10: Temos normalmente encontrados que a versão iniciais de sistemas que se assemelha BBoM foram rápidas para produzir um sucesso e bem-arredondado, mas porque houve pouco foco na necessidade do negócio, melhorias posteriores são problemáticos. A base de código não tem a necessária sinergia com o comportamento do negócio para fazer a mudança administrável. Este sentimento é resumida
• #11: O desafio de escrever E REFORÇAR O SOFTWARE para sistemas complexos e de larga escala vai muito além de quaisquer considerações técnicas. Na verdade, para domínios complexos , os desafios técnicos poderiam ser muito simples. É O apreço pela intenção do negócio que permitirá a equipe de desenvolvimento para identificar e investir seu tempo na parte mais importante do sistema . Como o negócio evoluira, que por sua vez ditará a evolucao do software; Ele precisa ser adaptavel, investir na qualidade do codigo e nas áreas-chave do sistema irá ajudar a mudar isso com o negócio. Se as areas fundamenstais do softawre nao estao em perfeita sinergia com o dominio do negocio entao seu software provavelmente aporederá se tornando uma bola de lama, e consequetemente resultando SOFTWARE DIFÍCIL manter. O Domain-Driven Aborda os desafios do gerenciamento e concepção de sistemas complexos grandes por primeiramente concentrar os esforços eno alinhamento do dominios computacionais com as capacidades de negócios e, segundo Revelando as peças principais de um sistema e assim entender onde os desenvolvedores devem colocar mais esforço. O alinhamento é feito por quebrar domínios de problemas grandes em MENORES subdomínios mais focado e dentro deles MENORES contextos de negócios . As partes centrais do sistema são encontrados por destilação do domínio do problema e entao revelar a razão fundamental por que o software está sendo produzido eo que será chave para seu sucesso
• #12: Uma vez que as áreas-chave do software são descobertas as equipes de desenvolvimento podem alavancar padroes táticos do Domain-Driven Design para construir um modelo conceitual, conhecido como um modelo de domínio, Este modelo não é um modelo de vida real, mas abstração para satisfazer as exigências dos casos de uso, embora mantendo o REGRAS e a lógica do domínio do negócio.
• #13: Pegue o modelo de domínio de uma aplicação de e-commerce. Há muitos componentes diferentes que formam o grande sistema global. Algumas peças podem ser encontrados em qualquer sistema de e-commerce, mas alguns vão ser exclusivo para sua empresa. Estas peças irão definir o software e serão as razões fundamentais que você está construindo em vez de comprar.
• #14: A destilação de conhecimento após sessões com especialistas de domínio deve revelar o que é único e importante sobre o aplicativo que você está prestes a criar. Você pode separar os subdomínios no núcleo, genérico, e apoiar domínios.
• #15: Pegue o modelo de domínio de uma aplicação de e-commerce. Há muitos componentes diferentes que formam o grande sistema global. Algumas peças podem ser encontrados em qualquer sistema de e-commerce, mas alguns vão ser exclusivo para sua empresa. Estas peças irão definir o software e serão as razões fundamentais que você está construindo em vez de comprar.
• #16: Para entender o que é central para o produto que a sua empresa está a pedir-lhe para se desenvolver, você precisa perguntar a si mesmo algumas perguntas. Quais são as partes do produto que irá torná-lo um sucesso? Por que essas partes do sistema são importantes? E por que não podem ser comprados na prateleira? Em outras palavras, o que torna o sistema algo que vale a pena construir? As peças principais do sistema representam a vantagem competitiva fundamental que sua empresa pode ganhar com a entrega deste software. O núcleo nem sempre é óbvio.
• #17: O DOMÍNIO representa a área problema que você está trabalhando dentro. É a realidade FIRME DA SITUAÇÃO. O modelo de domínio POR OUTRO LADO é uma abstração do domínio do problema, expressa como uma implementação de código que representa uma visao, não a realidade, do problema. A utilidade do modelo de domínio vem em sua capacidade de representar LÓGICA no domínio do problema para resolver problemas de negócios. O modelo é construído a partir da colaboração entre a equipe de desenvolvimento e especialistas em negócios. O modelo contém apenas o que é relevante para a resolução de problemas no contexto da aplicação que está sendo criado. Ela precisa evoluir constantemente com a empresa para manter-se útil e VÁLIDO. SÓ EXISTE PARA AJUDAR EUA resolver problemas, precisa ter CLAREZA E estar livre de complexidades técnicas.
• #18: Um modelo de domínio não é um modelo de vida real é um sistema de abstrações sobre a realidade, uma interpretação que inclui apenas os aspectos do domínio do problema que são predominantes para a resolução de casos específicos de uso de negócios. Um modelo de domínio deve excluir quaisquer detalhes irrelevantes de um domínio que não serve para resolver problemas. Modelos de Domínio conter apenas o que é relevante. Um modelo de domínio necessita de ser constantemente refinados, a fim de ser continuamente útil. Um modelo de domínio é sempre apenas temporalmente útil para uma determinada iteração e um conjunto de casos de uso. Casos de uso futuro, ou muda para o negócio pode tornar o modelo inútil.
• #19: COMMUNICATION! THE COLLABORATION BETWEEN THE BUSINESS EXPERT AND THE DEVELOPMENT TEAM IS AN ESSENTIAL ASPECT OF DDD AND ONE THAT IS CRUCIAL TO THE SUCCESS OF A PRODUCT UNDER DEVELOPMENT. HOWEVER, IT IS IMPORTANT TO SEEK OUT THOSE WHO ARE EXPERTS IN THE DOMAIN YOU ARE WORKING IN AND WHO CAN OFFER YOU DEEPER INSIGHT INTO THE PROBLEM AREA. DDD REFERS TO THESE SUBJECT MATTER EXPERTS AS DOMAIN EXPERTS. THE DOMAIN EXPERTS ARE THE PEOPLE WHO DEEPLY UNDERSTAND THE BUSINESS DOMAIN FROM ITS POLICIES AND WORK FLOWS, TO ITS NUISANCES AND IDIOSYNCRASIES. THEY ARE THE EXPERTS WITHIN THE BUSINESS OF THE DOMAIN; THEY WILL RARELY, IF EVER, HAVE THE TITLE DOMAIN EXPERT. INSTEAD, LOOK FOR THE PRODUCT OWNERS, USERS, AND ANYONE WHO HAS A GREAT GRASP AND UNDERSTANDING FOR THE DOMAIN YOU ARE WORKING IN REGARDLESS OF TITLE.
• #20: SER CAPAZ DE COMUNICAR DE FORMA EFICAZ É A HABILIDADE MAIS IMPORTANTE, SER CAPAZ DE RESOLVER PROBLEMAS. O DESENVOLVEDOR NÃO QUER CÓDIGO, ELE DEVE RESOLVER PROBLEMAS E POR ISSO É VITAL PARA FALAR COM O NEGÓCIO QUE VOCÊ ESTÁ TRABALHANDO EM UMA LINGUAGEM SEM AMBIGUIDADE OU NECESSIDADE DE TRADUÇÃO. REMOVENDO BARREIRAS LINGUÍSTICAS PROFISSIONAIS DO SECTOR E DA EQUIPE DE DESENVOLVIMENTO É LIVRE PARA COLABORAR EXPLORAR E EXPERIMENTAR COM DESENHOS PARA UM MODELO ÚTIL. IMPLEMENTAÇÕES TÉCNICAS PODEM SER EXPRESSAS UTILIZANDO AS LINGUAGEM UBÍQUA MESMO E QUAISQUER INSIGHTS PROJETO PODE ENTÃO SER ALIMENTADO DE VOLTA PARA ESPECIALISTAS DE DOMÍNIO PARA VALIDAÇÃO SEM NECESSIDADE DE TRADUÇÃO E PERDA DE SENTIDO. O VERDADEIRO VALOR DE SEGUIR A FILOSOFIA DOMAIN-DRIVEN DESIGN ESTÁ NA COLABORAÇÃO DE DESENVOLVEDORES E ESPECIALISTAS DE DOMÍNIO PARA PRODUZIR UMA MELHOR COMPREENSÃO DO DOMÍNIO. O CÓDIGO QUE É ESCRITA É APENAS UM ARTEFATO DESSE PROCESSO, EMBORA IMPORTANTE. PARA ALCANÇAR UMA MELHOR EQUIPES COMPREENSÃO PRECISA SE COMUNICAR DE FORMA EFICAZ. É A CRIAÇÃO DA LINGUAGEM UBÍQUA QUE PERMITE A COMPREENSÃO MAIS PROFUNDA QUE VAI VIVER APÓS O CÓDIGO SER REESCRITO E SUBSTITUÍDO.
• #21: Um especialista de domínio, irá trabalhar com você, a fim de produzir um modelo útil que pode satisfazer as necessidades de uma das partes interessadas.
• #22: Historicamente escrever softawe sempre foi um processo custoso, iterações demoradas, requisistos que eram levantados erronemente.
• #24: A partilha de informação permite que especialistas em negócios para contribuir para o design de software e fornece uma visão mais profunda e compreensão do domínio para a equipe de desenvolvimento . Depois de um período de tempo, desenvolvedores e especialistas em negócios vai descobrir a informação relevante para construir um modelo inicial do domínio do problema . Este modelo inicial é posta à prova , usando cenários de domínio : bens problemas do domínio de validar a sua utilidade . Modelagem em voz alta, usando os termos e linguagem do modelo , também pode ajudar a validar projetos iniciais.
• #25: DDD sugere um método mais colaborativa de capturar os requisitos do sistema e entender o fluxo de trabalho existente. A ênfase é colocada em toda a equipe , com especialistas em negócios e arquitetos (contanto que eles código ), com discussões em torno do espaço do problema . As discussões podem incluir qualquer documentação ou código legado que está relacionado com o sistema em questão . A idéia por trás das sessões de trituração colaborativa de conhecimento é para os desenvolvedores, testadores , analistas de negócios , arquitetos e especialistas em negócios para trabalhar como uma equipe unificada . Isso permite que os desenvolvedores e testadores para aprender sobre o significado por trás de termos de domínio e entender a lógica complexa na área do problema . Ele também permite que especialistas em negócios para experimentar as técnicas de modelagem empregadas. Com o entendimento de modelagem, especialistas em negócios si será capaz de modelar e validar projetos com a equipe de desenvolvimento.
• #26: Soluçao !!! A transição não é linear e sim distribuida, Os requisitos nao partem do UML para a codificação mas estes caminham lado a lado.