SlideShare uma empresa Scribd logo
26/06/2016 Thiago Veiga 1
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.
26/06/2016 Thiago Veiga 3
Key Words
26/06/2016 Thiago Veiga 4
Itens a definir
• O que é Design de Software ?
• O que é Modelo ?
• O que é Domínio ?
• Quais técnicas, conceitos e princípios estamos falando ?
26/06/2016 Thiago Veiga 5
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.
26/06/2016 Thiago Veiga 6
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
26/06/2016 Thiago Veiga 7
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.
26/06/2016 Thiago Veiga 8
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)
26/06/2016 Thiago Veiga 9
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.
26/06/2016 Thiago Veiga 10
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 ?
26/06/2016 Thiago Veiga 11
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.
26/06/2016 Thiago Veiga 12
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
26/06/2016 Thiago Veiga 13
Como funciona ?
O DDD utiliza desenvolvimento em camadas para encapsular as regras de
negócio no domínio.
Arquitetura em camadas
26/06/2016 Thiago Veiga 14
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.
26/06/2016 Thiago Veiga 15
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.
26/06/2016 Thiago Veiga 16
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
26/06/2016 Thiago Veiga 17
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
26/06/2016 Thiago Veiga 18
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.
26/06/2016 Thiago Veiga 19
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
26/06/2016 Thiago Veiga 20
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.
26/06/2016 Thiago Veiga 21
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
26/06/2016 Thiago Veiga 22
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.
26/06/2016 Thiago Veiga 23
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
26/06/2016 Thiago Veiga 24
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
26/06/2016 Thiago Veiga 25
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
26/06/2016 Thiago Veiga 26
Mapa de navegação
26/06/2016 Thiago Veiga 27
B.O. – Business Object
L.O. – Layer Object
V.O. – Value Object
Fuja da Arquitetura BOLOVOPara evitar
26/06/2016 Thiago Veiga 28
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
26/06/2016 Thiago Veiga 29
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.
26/06/2016 Thiago Veiga 30
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
26/06/2016 Thiago Veiga 31
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.
26/06/2016 Thiago Veiga 32
Bibliografia Recomendada
http://www.infoq.com/minibooks/domain-driven-design-quickly
http://dddcommunity.org/
26/06/2016 Thiago Veiga 33
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
26/06/2016 Thiago Veiga 34
26/06/2016 Thiago Veiga 35

Mais conteúdo relacionado

Mais procurados

Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel PimentelGestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Manoel Pimentel Medeiros
 
Identificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitosIdentificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitos
ptbr
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
Rildo (@rildosan) Santos
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 
Processos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e práticaProcessos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e prática
Ralph Rassweiler
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
CursoSENAC
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02
Franklin Matos Correia
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
Luís Fernando Richter
 
Processo de Análise e Desenvolvimento de Software (PDS)
Processo de Análise e Desenvolvimento de Software (PDS)Processo de Análise e Desenvolvimento de Software (PDS)
Processo de Análise e Desenvolvimento de Software (PDS)
Maicon Amarante
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Fernando Palma
 
técnicas de análise de requisitos
técnicas de análise de requisitostécnicas de análise de requisitos
técnicas de análise de requisitos
Katia Speck
 
Proposta para especificação de histórias de usuários alinhadas a IEEE 830
Proposta para especificação de histórias de usuários alinhadas a IEEE 830Proposta para especificação de histórias de usuários alinhadas a IEEE 830
Proposta para especificação de histórias de usuários alinhadas a IEEE 830
André Agostinho
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RON
Eduardo Castro
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
Paulo Furtado
 
Guia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de FunçãoGuia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de Função
Fernando Palma
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
Computação Depressão
 
20141128-Carlos-Eduardo-Capparelli
20141128-Carlos-Eduardo-Capparelli20141128-Carlos-Eduardo-Capparelli
20141128-Carlos-Eduardo-Capparelli
Carlos Eduardo Capparelli
 
Feature-Driven Development - Visão Geral
Feature-Driven Development - Visão GeralFeature-Driven Development - Visão Geral
Feature-Driven Development - Visão Geral
Ruan Carvalho
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
Felipe Goulart
 
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Elisangela Paulino
 

Mais procurados (20)

Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel PimentelGestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
Gestão Ágil de Projetos com Scrum e FDD - Manoel Pimentel
 
Identificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitosIdentificação de necessidades e estabelecimento de requisitos
Identificação de necessidades e estabelecimento de requisitos
 
Desenhando Componentes de Software com UML
Desenhando Componentes de Software com UMLDesenhando Componentes de Software com UML
Desenhando Componentes de Software com UML
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Processos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e práticaProcessos de Desenvolvimento de Software - teoria e prática
Processos de Desenvolvimento de Software - teoria e prática
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Introdução a engenharia de software aula 02
Introdução a engenharia de software   aula 02Introdução a engenharia de software   aula 02
Introdução a engenharia de software aula 02
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Processo de Análise e Desenvolvimento de Software (PDS)
Processo de Análise e Desenvolvimento de Software (PDS)Processo de Análise e Desenvolvimento de Software (PDS)
Processo de Análise e Desenvolvimento de Software (PDS)
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
técnicas de análise de requisitos
técnicas de análise de requisitostécnicas de análise de requisitos
técnicas de análise de requisitos
 
Proposta para especificação de histórias de usuários alinhadas a IEEE 830
Proposta para especificação de histórias de usuários alinhadas a IEEE 830Proposta para especificação de histórias de usuários alinhadas a IEEE 830
Proposta para especificação de histórias de usuários alinhadas a IEEE 830
 
Engenharia Requisitos - Método RON
Engenharia Requisitos - Método RONEngenharia Requisitos - Método RON
Engenharia Requisitos - Método RON
 
Levantamento Ágil de Requisitos
Levantamento Ágil de RequisitosLevantamento Ágil de Requisitos
Levantamento Ágil de Requisitos
 
Guia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de FunçãoGuia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de Função
 
Aula4 levantamento requisitos
Aula4 levantamento requisitosAula4 levantamento requisitos
Aula4 levantamento requisitos
 
20141128-Carlos-Eduardo-Capparelli
20141128-Carlos-Eduardo-Capparelli20141128-Carlos-Eduardo-Capparelli
20141128-Carlos-Eduardo-Capparelli
 
Feature-Driven Development - Visão Geral
Feature-Driven Development - Visão GeralFeature-Driven Development - Visão Geral
Feature-Driven Development - Visão Geral
 
Engenharia De Software
Engenharia De SoftwareEngenharia De Software
Engenharia De Software
 
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
Analise de gerenciamento_de_projeto_de_software_utilizando_metodologia_agil_x...
 

Destaque

Set 3 18 h
Set 3   18 hSet 3   18 h
Set 3 18 h
Ttx Love
 
MongoDB Europe 2016 - MongoDB Atlas
MongoDB Europe 2016 - MongoDB AtlasMongoDB Europe 2016 - MongoDB Atlas
MongoDB Europe 2016 - MongoDB Atlas
MongoDB
 
U boot-boot-flow
U boot-boot-flowU boot-boot-flow
Top Use Cases for Desktop Virtualization
Top Use Cases for Desktop VirtualizationTop Use Cases for Desktop Virtualization
Top Use Cases for Desktop Virtualization
Citrix
 
Machine Learning - Challenges, Learnings & Opportunities
Machine Learning - Challenges, Learnings & OpportunitiesMachine Learning - Challenges, Learnings & Opportunities
Machine Learning - Challenges, Learnings & Opportunities
CodePolitan
 
Digital or die? British boardrooms divided on digital transformation
Digital or die? British boardrooms divided on digital transformationDigital or die? British boardrooms divided on digital transformation
Digital or die? British boardrooms divided on digital transformation
Citrix
 
MongoDB 3.4 webinar
MongoDB 3.4 webinarMongoDB 3.4 webinar
MongoDB 3.4 webinar
Andrew Morgan
 
MongoDB Europe 2016 - Debugging MongoDB Performance
MongoDB Europe 2016 - Debugging MongoDB PerformanceMongoDB Europe 2016 - Debugging MongoDB Performance
MongoDB Europe 2016 - Debugging MongoDB Performance
MongoDB
 
2.3 ingatan dan lupaan
2.3 ingatan dan lupaan2.3 ingatan dan lupaan
2.3 ingatan dan lupaan
Farah Husna
 
Linux Internals - Interview essentials - 1.0
Linux Internals - Interview essentials - 1.0Linux Internals - Interview essentials - 1.0
Linux Internals - Interview essentials - 1.0
Emertxe Information Technologies Pvt Ltd
 
Cong nghe top base
Cong nghe top baseCong nghe top base
Cong nghe top base
licogi168
 
MongoDB World 2016: Keynote
MongoDB World 2016: KeynoteMongoDB World 2016: Keynote
MongoDB World 2016: Keynote
MongoDB
 
How To Connect Spark To Your Own Datasource
How To Connect Spark To Your Own DatasourceHow To Connect Spark To Your Own Datasource
How To Connect Spark To Your Own Datasource
MongoDB
 
MongoDB Launchpad 2016: MongoDB 3.4: Your Database Evolved
MongoDB Launchpad 2016: MongoDB 3.4: Your Database EvolvedMongoDB Launchpad 2016: MongoDB 3.4: Your Database Evolved
MongoDB Launchpad 2016: MongoDB 3.4: Your Database Evolved
MongoDB
 
US 06062016NY CLResu1.
US 06062016NY CLResu1.US 06062016NY CLResu1.
US 06062016NY CLResu1.
Alrahaaal ALsahraaa
 

Destaque (15)

Set 3 18 h
Set 3   18 hSet 3   18 h
Set 3 18 h
 
MongoDB Europe 2016 - MongoDB Atlas
MongoDB Europe 2016 - MongoDB AtlasMongoDB Europe 2016 - MongoDB Atlas
MongoDB Europe 2016 - MongoDB Atlas
 
U boot-boot-flow
U boot-boot-flowU boot-boot-flow
U boot-boot-flow
 
Top Use Cases for Desktop Virtualization
Top Use Cases for Desktop VirtualizationTop Use Cases for Desktop Virtualization
Top Use Cases for Desktop Virtualization
 
Machine Learning - Challenges, Learnings & Opportunities
Machine Learning - Challenges, Learnings & OpportunitiesMachine Learning - Challenges, Learnings & Opportunities
Machine Learning - Challenges, Learnings & Opportunities
 
Digital or die? British boardrooms divided on digital transformation
Digital or die? British boardrooms divided on digital transformationDigital or die? British boardrooms divided on digital transformation
Digital or die? British boardrooms divided on digital transformation
 
MongoDB 3.4 webinar
MongoDB 3.4 webinarMongoDB 3.4 webinar
MongoDB 3.4 webinar
 
MongoDB Europe 2016 - Debugging MongoDB Performance
MongoDB Europe 2016 - Debugging MongoDB PerformanceMongoDB Europe 2016 - Debugging MongoDB Performance
MongoDB Europe 2016 - Debugging MongoDB Performance
 
2.3 ingatan dan lupaan
2.3 ingatan dan lupaan2.3 ingatan dan lupaan
2.3 ingatan dan lupaan
 
Linux Internals - Interview essentials - 1.0
Linux Internals - Interview essentials - 1.0Linux Internals - Interview essentials - 1.0
Linux Internals - Interview essentials - 1.0
 
Cong nghe top base
Cong nghe top baseCong nghe top base
Cong nghe top base
 
MongoDB World 2016: Keynote
MongoDB World 2016: KeynoteMongoDB World 2016: Keynote
MongoDB World 2016: Keynote
 
How To Connect Spark To Your Own Datasource
How To Connect Spark To Your Own DatasourceHow To Connect Spark To Your Own Datasource
How To Connect Spark To Your Own Datasource
 
MongoDB Launchpad 2016: MongoDB 3.4: Your Database Evolved
MongoDB Launchpad 2016: MongoDB 3.4: Your Database EvolvedMongoDB Launchpad 2016: MongoDB 3.4: Your Database Evolved
MongoDB Launchpad 2016: MongoDB 3.4: Your Database Evolved
 
US 06062016NY CLResu1.
US 06062016NY CLResu1.US 06062016NY CLResu1.
US 06062016NY CLResu1.
 

Semelhante a DDD

Es 09
Es 09Es 09
Domain Driven Design - Aplicando estrategias e padrões
Domain Driven Design - Aplicando estrategias e padrõesDomain Driven Design - Aplicando estrategias e padrões
Domain Driven Design - Aplicando estrategias e padrões
Joao Paulo Oliveira dos Santos
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
Daniel Everling
 
Frameworks de desenvolvimento web
Frameworks de desenvolvimento webFrameworks de desenvolvimento web
Frameworks de desenvolvimento web
Arlindo Santos
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de banana
ejedelmal
 
Artigo23
Artigo23Artigo23
Artigo23
mpaf00 mpaf00
 
Uma introdução ao Domain Driven Design
Uma introdução ao Domain Driven DesignUma introdução ao Domain Driven Design
Uma introdução ao Domain Driven Design
Lambda3
 
tdc-2022-poa-quem-tem-medo-low-code.pdf
tdc-2022-poa-quem-tem-medo-low-code.pdftdc-2022-poa-quem-tem-medo-low-code.pdf
tdc-2022-poa-quem-tem-medo-low-code.pdf
Douglas Siviotti
 
Como implantar transformações organizacionais a partir de uma plataforma BPMS...
Como implantar transformações organizacionais a partir de uma plataforma BPMS...Como implantar transformações organizacionais a partir de uma plataforma BPMS...
Como implantar transformações organizacionais a partir de uma plataforma BPMS...
Lecom Tecnologia
 
– Como implantar transformações organizacionais a partir de uma plataforma BP...
– Como implantar transformações organizacionais a partir de uma plataforma BP...– Como implantar transformações organizacionais a partir de uma plataforma BP...
– Como implantar transformações organizacionais a partir de uma plataforma BP...
EloGroup
 
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
EloGroup
 
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SITeoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
Alessandro Almeida
 
Domain-Driven Design - Uma Abordagem Introdutória
Domain-Driven Design - Uma Abordagem IntrodutóriaDomain-Driven Design - Uma Abordagem Introdutória
Domain-Driven Design - Uma Abordagem Introdutória
armeniocardoso
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
Ítalo Bandeira
 
Saa s software como serviço (slides)
Saa s   software como serviço (slides)Saa s   software como serviço (slides)
Saa s software como serviço (slides)
Daniela Nunes
 
Domain driven design - Visão Geral
Domain driven design - Visão GeralDomain driven design - Visão Geral
Domain driven design - Visão Geral
Lorival Smolski Chapuis
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
André Borgonovo
 
Artigo
ArtigoArtigo
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Carolina Karklis
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
Rennan Martini
 

Semelhante a DDD (20)

Es 09
Es 09Es 09
Es 09
 
Domain Driven Design - Aplicando estrategias e padrões
Domain Driven Design - Aplicando estrategias e padrõesDomain Driven Design - Aplicando estrategias e padrões
Domain Driven Design - Aplicando estrategias e padrões
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Frameworks de desenvolvimento web
Frameworks de desenvolvimento webFrameworks de desenvolvimento web
Frameworks de desenvolvimento web
 
Fdd em uma casca de banana
Fdd em uma casca de bananaFdd em uma casca de banana
Fdd em uma casca de banana
 
Artigo23
Artigo23Artigo23
Artigo23
 
Uma introdução ao Domain Driven Design
Uma introdução ao Domain Driven DesignUma introdução ao Domain Driven Design
Uma introdução ao Domain Driven Design
 
tdc-2022-poa-quem-tem-medo-low-code.pdf
tdc-2022-poa-quem-tem-medo-low-code.pdftdc-2022-poa-quem-tem-medo-low-code.pdf
tdc-2022-poa-quem-tem-medo-low-code.pdf
 
Como implantar transformações organizacionais a partir de uma plataforma BPMS...
Como implantar transformações organizacionais a partir de uma plataforma BPMS...Como implantar transformações organizacionais a partir de uma plataforma BPMS...
Como implantar transformações organizacionais a partir de uma plataforma BPMS...
 
– Como implantar transformações organizacionais a partir de uma plataforma BP...
– Como implantar transformações organizacionais a partir de uma plataforma BP...– Como implantar transformações organizacionais a partir de uma plataforma BP...
– Como implantar transformações organizacionais a partir de uma plataforma BP...
 
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
[Café com BPM - Setor Privado] Como implantar transformações organizacionais ...
 
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SITeoria de Sistemas de Informação - Atividade: Tecnologia e SI
Teoria de Sistemas de Informação - Atividade: Tecnologia e SI
 
Domain-Driven Design - Uma Abordagem Introdutória
Domain-Driven Design - Uma Abordagem IntrodutóriaDomain-Driven Design - Uma Abordagem Introdutória
Domain-Driven Design - Uma Abordagem Introdutória
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
 
Saa s software como serviço (slides)
Saa s   software como serviço (slides)Saa s   software como serviço (slides)
Saa s software como serviço (slides)
 
Domain driven design - Visão Geral
Domain driven design - Visão GeralDomain driven design - Visão Geral
Domain driven design - Visão Geral
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
 
Artigo
ArtigoArtigo
Artigo
 
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 

Último

Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
joaovmp3
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
WELITONNOGUEIRA3
 

Último (8)

Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
 

DDD

  • 2. 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.
  • 4. 26/06/2016 Thiago Veiga 4 Itens a definir • O que é Design de Software ? • O que é Modelo ? • O que é Domínio ? • Quais técnicas, conceitos e princípios estamos falando ?
  • 5. 26/06/2016 Thiago Veiga 5 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.
  • 6. 26/06/2016 Thiago Veiga 6 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
  • 7. 26/06/2016 Thiago Veiga 7 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.
  • 8. 26/06/2016 Thiago Veiga 8 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)
  • 9. 26/06/2016 Thiago Veiga 9 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.
  • 10. 26/06/2016 Thiago Veiga 10 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 ?
  • 11. 26/06/2016 Thiago Veiga 11 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.
  • 12. 26/06/2016 Thiago Veiga 12 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
  • 13. 26/06/2016 Thiago Veiga 13 Como funciona ? O DDD utiliza desenvolvimento em camadas para encapsular as regras de negócio no domínio. Arquitetura em camadas
  • 14. 26/06/2016 Thiago Veiga 14 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.
  • 15. 26/06/2016 Thiago Veiga 15 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.
  • 16. 26/06/2016 Thiago Veiga 16 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
  • 17. 26/06/2016 Thiago Veiga 17 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
  • 18. 26/06/2016 Thiago Veiga 18 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.
  • 19. 26/06/2016 Thiago Veiga 19 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
  • 20. 26/06/2016 Thiago Veiga 20 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.
  • 21. 26/06/2016 Thiago Veiga 21 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
  • 22. 26/06/2016 Thiago Veiga 22 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.
  • 23. 26/06/2016 Thiago Veiga 23 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
  • 24. 26/06/2016 Thiago Veiga 24 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
  • 25. 26/06/2016 Thiago Veiga 25 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
  • 26. 26/06/2016 Thiago Veiga 26 Mapa de navegação
  • 27. 26/06/2016 Thiago Veiga 27 B.O. – Business Object L.O. – Layer Object V.O. – Value Object Fuja da Arquitetura BOLOVOPara evitar
  • 28. 26/06/2016 Thiago Veiga 28 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
  • 29. 26/06/2016 Thiago Veiga 29 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.
  • 30. 26/06/2016 Thiago Veiga 30 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
  • 31. 26/06/2016 Thiago Veiga 31 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.
  • 32. 26/06/2016 Thiago Veiga 32 Bibliografia Recomendada http://www.infoq.com/minibooks/domain-driven-design-quickly http://dddcommunity.org/
  • 33. 26/06/2016 Thiago Veiga 33 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