DDD

26/06/2016 Thiago Veiga 2
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.

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 BOLOVOPara 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/

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

DDD

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (15)

Semelhante a DDD

Semelhante a DDD (20)

Último

Último (6)

DDD