ddd

26/06/2016 Thiago Veiga 1


Definindo Domain Driven Design

Não é uma tecnologia ou metodologia, mas sim uma abordagem de design de software disciplinada que reune um conjunto de conceitos, técnicas e princípios com foco no domínio e na lógica do domínio para criar um modelo do domínio.

Domain-Driven Design é uma abordagem de projeto de software que tem como um dos objetivos permitir a criação de objetos de domínio que falem a lingua do negócio e sejam indenpendentes da infraestrutura utilizada. Ou seja, o foco passa a ser o domínio do negócio e não mais a tecnologia.


Key Words


Itens a definir

• O que é Design de Software ?

• O que é Modelo ?

• O que é Domínio ?

• Quais técnicas, conceitos e princípios estamos falando ?


Definindo Design de Software

Software design is an art, and like any art it cannot be taught and learned as a precise science, by means of theorems and formulas (Floyd Marinescu)

• Design de software geralmente envolve a resolução de problemas e planejamento de uma solução de software . Isso inclui tanto um componente de baixo nível (projeto de algoritmos) e um alto nível , projeto de arquitetura.

Design de software é o processo de implementação de soluções de software para um ou mais conjuntos de problemas. Um dos principais componentes do design de software é a análise de requisitos de software.

http://www.floydmarinescu.com/

http://www.floydmarinescu.com/


Definindo Modelo

Modelo é uma simplificação. Ele é uma interpretação da realidade que destaca os aspectos relevantes para resolver o problema que se tem em mãos ignorando os detalhes estranhos (Eric Evans)

• Modelo pode ser expresso de muitas formas como rascunhos, desenhos, uml ou código

• Modelo é uma forma de conhecimento seletivamente simplificada e conscientemente estruturada


Definindo o domínio

A Área de assunto em que o usuário aplica o programa é o domínio do software.

• Os domínio de software geralmente tem pouco a ver com computadores, embora possa existir exceções

O domínio de um software é “a área de ação, conhecimento e influência do software”. Sendo assim, focar no domínio é dar mais atenção à área de negócio que o software pretende cobrir do que a detalhes sobre tecnologias a serem empregadas em seu desenvolvimento.


Algumas técnicas, conceitos e princípios dos quais estamos falando • T.D.D. - Test-driven Design, mais uma metodologia de projeto do que uma estratégia de testes. O

principal conceito por trás disso é permitir que seus testes modelem a forma do design do sistema

• B.D.D. - Behavior-driven Design, uma evolução do TDD com alguns conceitos de DDD, focando no comportamento do sistema somado a um desenvolvimento visando testes

• Orientação a Objetos - é um modelo de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos.

• D.S.L – Domain Specific Language, são os paradgimas e funções, ou códigos específicos, de uma linguagem de programação ou linguagem de especificação em desenvolvimento de software e engenharia de domínio, dedicada a um domínio de problema particular, uma técnica de representação de problema particular e/ou uma técnica de solução particular.

• Arquitetura em camadas - Um programa de aplicação em n camadas é um aplicativo desenvolvido de forma a ter várias camadas lógicas. Cada camada é auto-contida o suficiente de forma que a aplicação pode ser dividida em vários computadores em uma rede distribuída.

• Design Pattern - é uma solução geral reutilizável para um problema que ocorre com frequência dentro de um determinado contexto no projeto de software

• Strategic Design - é um princípio de design orientado para o futuro , a fim de aumentar as qualidades inovadoras e competitivas de uma organização

• Ubiquitous Language - Linguagem ubíqua é o termo Eric Evans usa em Domain Driven Design para a prática de construção de uma linguagem comum , rigorosa entre desenvolvedores e usuários. Esta linguagem deve basear-se no modelo de domínio usada no software - daí a necessidade de que seja rigorosa , uma vez que o software não lida bem com a ambiguidade. (Martin Fowler)


Por que DDD ? Quais as vantagens ?

• Alinha o conhecimento dos desenvolvedores e dos domain experts produzindo software mais coerente com o negócio e reduzindo as chances de que o conhecimento sobre o domain model fique nas mãos de poucas ou de uma única pessoa.

• O design É o código e não há traduções entre desenvolvedores e domain experts porque todos compartilham a mesma linguagem.

• Fornece práticas em nível tático, na criação de um domain model sólido, e em nível estratégico, auxiliando na identificação das áreas mais importantes a serem atacadas e como essas áreas se comunicam.

• O maior valor da prática está no foco no negócio principal da empresa, naquilo que é – ou pode ser – seu diferencial competitivo (chamado de Core Domain).

• Melhor experiência de usuário, uma vez que as telas do software passam a refletir uma operação de negócio

• Código expressando melhor o negócio e arquitetura da solução melhor organizada.


Quando usar DDD ?

• O software irá atender uma área de negócio muito específica e complexa, onde ninguém ou poucos possuem conhecimento.

• Há muitas operações de negócio (dezenas).

• Há mudanças frequentes nas funcionalidades e regras.

• O software é um pequeno aplicativo de suporte da empresa, como, por exemplo, um software composto basicamente de alguns CRUDs ou uma API de consulta que basicamente busca alguns dados e os retorna em algum formato específico.

Quando não usar DDD ?


Como funciona ? Linguagem Ubíqua

Para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua. Nessa linguagem estão os termos que fazem parte das conversas diárias entre especialistas de negócio, times de desenvolvimento e todos os envolvidos no projeto. Todos devem usar os mesmos termos tanto na linguagem falada quanto no código, diagramas ou qualquer outro tipo de documento relativo ao projeto. A linguagem ubíqua deve ser compreendida por todos e não podem haver ambigüidades. Toda vez que alguém perceber que um determinado conceito do domínio possui várias palavras que o represente, deve-se readequar tanto a linguagem falada e escrita, quanto o código. Caso existam palavras de dificil compreensão estas devem ser esclarecidas e caso não estejam de acordo com o domínio devem ser descartadas e/ou substituidas. Em seguida toda a documentação, código e etc devem ser revistos.


Como funciona ? Linguagem Ubíqua

Se em um sistema de cobrança, por exemplo, o analista de negócio disser: “Temos que emitir a fatura para o cliente antes da data limite“, vamos tem no nosso código alguma coisa do tipo:

• uma classe para a entidade Cliente

• uma classe para a entidade Fatura

• um serviço que tenha um método emitir

• um atributo que chame data limite


Como funciona ?

O DDD utiliza desenvolvimento em camadas para encapsular as regras de negócio no domínio.

Arquitetura em camadas


Arquitetura em camadas – Camada de apresentação

Fazem parte da camada de apresentação todos os componentes utilizados para fazer interface com o usuário. É crítica, pois, é através dela que o usuário completa suas tarefas. Ela precisa ser efetiva, leve e agradável. Para isso, precisa: • Ser orientada a tarefas (behavior driven) • Ajustada para o device • Amigável para o usuário. A camada de apresentação deve "conversar" apenas com a camada de Aplicação consumindo, apenas eventualmente, recursos fornecidos pela Infraestrutura. Em uma aplicação MVC, podemos assumir que as Views fazem parte da camada de apresentação, bem como todo HTML.


Arquitetura em camadas – Camada de Aplicação

Fazem parte da camada de aplicação todos os componentes responsáveis por receber requisições da camada de apresentação e prover dados para ela. A camada de aplicação deve: • Fornecer dados "prontos para usar" para a apresentação. Não deveria ser

necessário nenhuma transformação ou processamento intensivo; • Orquestrar a execução de tarefas iniciadas pelos elementos de interface; • fornecer dados para a camada de Aplicação através de Input Models. De

outro lado, a Aplicação deve fornecer dados para a Apresentação via View Models.

Em uma aplicação MVC, o controller faz parte da camada de aplicação. Os componentes da camada de Aplicação são DTOs e serviços de aplicação.


Arquitetura em camadas – Camada de Domínio

Fazem parte da camada de domínio todos os componentes que implementam as regras de negócio e/ou organizam a lógica do negócio. No DDD, é na camada de domínio que você implementa: • Modelos de Domínio (Entidades, Value Types, Agregados, etc) • Serviços de domínio (repositórios, processadores de comandos, etc.) • Conexão com serviços/aplicativos externos


Arquitetura em camadas – Camada de Infra-estrutura

Fazem parte da camada de infraestrutura todos os componentes necessários para o suporte de execução da aplicação. É responsabilidade da camada de Infraestrutura: • Persistência • Segurança • Logging • Containers de Inversão de Controle • Caching • Conectividade


Como funciona ?

O Model Driven Design possuí vários Padrões, que são os blocos de construção que fazem a representação do modelo abstrato

MDD - Model Driven Design

A abordagem MDD ao desenvolvimento de software permite que as pessoas trabalhem juntas em um projeto, mesmo com níveis de experiência individuais muito diferentes. O MDD permite que uma empresa maximize o trabalho eficaz em um projeto enquanto minimiza a sobrecarga necessária para produzir software que possa ser validado pelos usuários finais no menor tempo possível. Em MDD , a metodologia é ágil e está em constante evolução para atender às necessidades do negócio.


Como funciona ?

Para construir uma aplicação com DDD, levando a regra de negócio do modelo para o software é necessário conhecermos os conceitos de Entidades, Objetos de Valor, Repositórios, Serviços e Factores.

Blocos de Contrução


Blocos de Contrução - Entity

• Têm significado no domínio.

• Possuem identidade.

• Uma entidade do domínio possui regras de negócio.

• Também não conhece nenhuma outra classe fora do domínio.

• Ela não deve possuir dependências externas nem conhecer como será persistida.


Blocos de Contrução - Factory

• Criar objetos com todas as suas dependências e agregações e em estado consistente

• No DDD, quando precisamos criar um Entidade complexa é necessário utilizarmos uma fábrica para que possamos reutilizá-la ao longo do projeto


Blocos de Contrução – Objeto de valor

• Não têm identidade para o negócio.

• São reconhecidos pelos seus atributos.

• Não são persistidos.


Blocos de Contrução – Repositório

• Padrão de Projeto Repository

• Acesso à dados

• Responsiveis por criar e destuir objetos

• geralmente fazem parte da camada de infra-estrutura


Blocos de Contrução – Serviços

• Resolvem problemas do negócio

• Não são entidades nem objetos de valor

• Não controlam nem possuem estado do negócio


Blocos de Contrução – Agregações

• Encapsulam entidades e objetos de valor de maneira que faça sentido para o negócio.

• Possuem uma raiz.

• Definem fronteiras claras, provendo para um cliente externo da classe uma interface de acesso aos objetos da agregação


Mapa de navegação


B.O. – Business Object

L.O. – Layer Object

V.O. – Value Object

Fuja da Arquitetura BOLOVO Para evitar


Erros mais comuns

• Permitir que a persistência ou repositório de dados influencie no modelo.

• Não se envolver com os especialistas do domínio.

• Ignorar a linguagem dos especialistas do domínio.

• Não identificar a fronteira e a limitação dos contextos.

• Usar um modelo de domínio anêmico.

• Assumir que toda lógica é a lógica do domínio.

• Fazer uso excessivo de testes de integração.

• Tratar aspectos de segurança como parte do domínio (a menos que se esteja trabalhando em um domínio de segurança).

• Concentrar-se na infraestrutura.

Para evitar


Melhoria Continua Refatorando

O modelo deve ser refatorado na medida em que se compreende mais e mais novos conceitos do domínio. Muitas vezes alguns conceitos do domínio estão implícitos no código. Nosso trabalho é tentar identificar esse conceitos implícitos e torná-los explícitos

• Interface de Intenção Revelada – usar nomes de métodos ou classes que dizem exatamente o que essas classes e métodos fazem, mas não como elas fazem.

• Funções sem Efeitos-Colaterais – tentar deixar o código com o maior número possível de métodos que não alteram o estado dos objetos, concentrando esse tipo de operação (alteração de estado) em Comandos.

• Asserções – para os Comandos que alteram estados, criar testes de unidade, ou colocar asserções no código que validem, após a chamada dos comandos, as alterações de estado esperadas.


Planejamento Estratégico

Algumas estratégias são necessárias para lidar com sistemas complexos, onde vários modulos do sistema, geralmente desenvolvidos por diferentes times interagem entre si. Delimitar em que contexto cada time trabalha e qual será o grau de interação entre times e contextos. Para isso os padrões:

• Contexto delimitado – um traçado perfeito sobre o que pertence e o que não pertence a um contexto

• Mapa entre Contextos – uma forma de documentar claramente termos usados para um mesmo conceito em vários contextos

• Camada Anti-corrupção – quando temos um sistema legado, com código muito bagunçado e uma interface complexa, e estamos escrevendo um sistema novo com o código razoavelmente bem feito, criamos uma camada entre esses dois sistemas

• Núcleo Compartilhado – Quando um recurso , geralmente o banco de dados é compartilhado por mais de um time


Conclusão

Em poucas palavras, DDD é uma coleção de padrões e princípios que ajudam em seus esforços para construir aplicações que refletem uma compreensão e a satisfação das exigências do seu negócio. Fora isso, é inteiramente uma nova maneira de pensar sobre a sua metodologia de desenvolvimento. DDD trata da modelagem do domínio real por primeiramente entendê-la completamente e então colocar todas as terminologias, regras, e lógica em uma representação abstrata dentro do seu código, tipicamente em forma de um modelo de domínio. DDD não é um framework, mas ele tem um conjunto de blocos ou conceitos que podem ser incorporados em sua solução. Podemos entender DDD como uma automatização do processo de negócio, de modo que o foco é no domínio do software a fim de atender completamente um determinado negócio.


Bibliografia Recomendada

http://www.infoq.com/minibooks/domain-driven-design-quickly

http://dddcommunity.org/








http://dddcommunity.org/


Bibliografia

• Domain Driven Design – Atacando a complexidade no Coração do Software Eric Evans • http://martinfowler.com/ • https://www.infoq.com • https://www.wikipedia.org/ • http://www.devmedia.com.br

http://martinfowler.com/

http://martinfowler.com/

https://www.infoq.com/

https://www.infoq.com/

https://www.wikipedia.org/




http://www.devmedia.com.b/

ddd

Technology