SlideShare uma empresa Scribd logo
Domain Driven Design
Aplicando Estratégias e Padrões
João Paulo Santos, MSc
1
 Formação
 Mestre em Sistemas de Informação – UNIRIO
 Linha de pesquisa: Sistemas de Apoio a Negócios
 Pós-Graduado em Gerenciamento de Projetos – FGV
 Bacharel em Informática - UERJ
 Coordenador Pedagógico do MIT em Arquitetura de Software
 Professor de Graduação e Pós-Graduação
 Infnet, Decision (FGV-POA), UERJ
 Experiência de Mercado
 + de 15 anos com Integração de Sistemas,Arquitetura de Software,Análise e Desenvolvimento
de Sistemas
 Arquiteto de Sistemas focado na definição dos componentes de software e integração das
soluções da Gestora de Recursos do Banco do Brasil. Possui mais de 15 anos de experiência
atuando nas áreas de Integração de Sistemas,Arquitetura de Software,Análise e Desenvolvimento
de Sistemas
Domain Driven Design – Aplicando Estratégias e Padrões 2
Quem sou...
 Abordar sucintamente os principais conceitos de Domain Driven Design.
 Discutir e demonstrar a aplicação de estratégias e padrões na elaboração
de um modelo de domínio.
Objetivos
Domain Driven Design – Aplicando Estratégias e Padrões 3
 Estudantes de graduação e pós-graduação nas áreas de sistemas de
software
 Analistas e desenvolvedores de software
 Arquitetos de software
Publico alvo
Domain Driven Design – Aplicando Estratégias e Padrões 4
 Contextualização : modelo, domínio e modelo de domínio
 Problemas com a orientação a objetos
 Conceitos básicos de DDD
 Técnicas para modelagem de domínio
 Padrões de domínio
Agenda
Domain Driven Design – Aplicando Estratégias e Padrões 5
Domain Driven Design – Aplicando Estratégias e Padrões 6
O que é isso?
 É uma simplificação
 Representa algum aspecto da realidade com uma ideia que seja de interesse
 Interpretação da realidade que destaca os aspectos relevantes para
resolver o problema
 Ignora os detalhes “estranhos”
Domain Driven Design – Aplicando Estratégias e Padrões 7
Modelo
 Área de conhecimento
 Área de interesse dos usuários
 Exemplo:
 Domínios do mundo físico:
 Programa de reserva de passagens aéreas – pessoas reais entrando em aeronaves reais
 Domínio intangível:
 Programa de contabilidade – dinheiro e as finanças
Domínio
Domain Driven Design – Aplicando Estratégias e Padrões 8
“Os modelos de domínios podem trazer grandes vantagens para o controle do
desenvolvimento de softwares – sejam quais forem a linguagem e o ambiente em
que eles sejam implementados”
Martin Fowler
Domain Driven Design – Aplicando Estratégias e Padrões 9
 Ferramenta para atacar a sobrecarga de informação e complexidade de um
domínio
 É uma forma de abstração rigorosamente organizada e seletiva do
conhecimento dos especialistas
 Dá sentido as informações
 Concentra-se em um problema
Modelo de Domínio
Domain Driven Design – Aplicando Estratégias e Padrões 10
 Um diagrama específico
 Uma questão de se criar um modelo o mais realista possível e sim é uma
criação artificial
 Simplesmente a criação de um mecanismo de software que forneça os
resultados necessários
Modelo de Domínio Não é
Domain Driven Design – Aplicando Estratégias e Padrões 11
 O modelo e o coração do design dão forma um ao outro
 O modelo é a “espinha dorsal” de uma linguagem utilizada por todos os
membros da equipe
 O modelo é um conhecimento destilado
Modelo de Domínio é útil para:
Domain Driven Design – Aplicando Estratégias e Padrões 12
Lembra?
Domain Driven Design – Aplicando Estratégias e Padrões 13
1980 1986
1969 - Smaltalk
 Foco em Arquitetura e Design (independente do domínio)
 Ferramentas e frameworks têm, silenciosamente, deturpado os valores
originais da POO
Por que a POO não é suficiente?
Domain Driven Design – Aplicando Estratégias e Padrões 14
“Falta disciplina para modelagem
de domínios grandes e complexos”
 O foco principal para construção de sistemas deveria ser no domínio e na
lógica do negócio
 O design de um domínio complexo deveria ser baseado em um modelo
Por que a POO não é suficiente?
Domain Driven Design – Aplicando Estratégias e Padrões 15
Solução...
Domain Driven Design – Aplicando Estratégias e Padrões 16
 É um conjunto de técnicas comprovadas de modelagem notadamente para
aplicações complexas
 É um conjunto de princípios e práticas que dão suporte ao processo de
desenvolvimento
 É um conjunto de padrões que formam um visão coesa e coerente do
modelo de domínio
 É um conjunto de estratégias que permitem escalar aplicações em tamanho
e complexidade
Domain Driven Design
Domain Driven Design – Aplicando Estratégias e Padrões 17
 O time e os experts no domínio trabalham de forma contínua (e iterativa)
refinando o modelo e buscando melhor compreensão do problema a ser
solucionado
 Os canais de comunicação entre os domain experts e o time devem estar
sempre abertos
DDD e Colaboração
Domain Driven Design – Aplicando Estratégias e Padrões 18
 Modelo e Design devem evoluir em sincronia –
desenvolvimento contínuo
 O código é a última (e mais importante) forma
de expressão do modelo
 Artefatos intermediários servem basicamente
como documentos temporários
Modelo de Domínio e Design
Domain Driven Design – Aplicando Estratégias e Padrões 19
Domain Driven Design – Aplicando Estratégias e Padrões 20
Como entender o negócio e modelar um domínio corretamente?
Desenvolvedores Especialista do domínio
 Foco em classes, métodos,
algoritmos, padrões
 Comparações entre conceitos da
vida real e artefatos de
programação
 Criação de classes de objeto e
suas relações com o modelo
 Pensam em termos de
encapsulamento, herança e
polimorfismo
 Foco em suas competências
específicas
 Não conhecem sobre
desenvolvimento de software e
nem técnicas de modelagem
 Não tem idéia do que é um
framework, persistência e em
muitos casos nem sobre bancos
de dados
Domain Driven Design – Aplicando Estratégias e Padrões 21
A necessidade de uma linguagem comum
 Os especialistas do domínio conhecem:
 Ordem de negócio
 Ações
 Stop Loss
 Pu,Var,Tir, PL
 Fluxo de Caixa
 Utilizam um jargão próprio que não é facilmente compreendido pelos
membros da equipe técnica
 A equipe técnica também possui o seu próprio jargão:
 Query, SQL, SGBD
 Patterns
 MaquinaVirtual
Exemplo – Mercado Financeiro
Domain Driven Design – Aplicando Estratégias e Padrões 22
 A Comunicação é fundamental para o sucesso do
projeto
 Se um diz algo e os outros não entendem, ou pior,
entendem em outra conotação, quais são as chances
de sucesso deste projeto?
Problemas de Comunicação
Domain Driven Design – Aplicando Estratégias e Padrões 23
Precisamos falar a mesma linguagem
Domain Driven Design – Aplicando Estratégias e Padrões 24
Linguagem Ubíqua
 Conecta-se a todas as partes do design
 Define premissas e conceitos
 Leva semanas e até meses para tomar forma em
projetos de grande complexidade
 Os especialistas devem atentar para os termos
que transmitam o adequado conhecimento do
domínio
 Desenvolvedores devem atentar para eventuais
ambigüidades ou incoerência
Domain Driven Design – Aplicando Estratégias e Padrões 25
 Linguagem Ubíqua viabiliza a elaboração
do modelo de domínio
 Profissionais que modelam o domínio
também codificam o software
 Programadores devem se sentir também
responsáveis pelo modelo, caso
contrário não haverá relação do código
com o modelo
 Processo de maturação contínuo
Linguagem Ubíqua – Modelo de Domínio
Domain Driven Design – Aplicando Estratégias e Padrões 26
 Resolução dos problemas do domínio é realizada por uma pequena parte
do sistema
 Os elementos do domínio devem ser visto como um sistema
 Os objetos do domínio devem estar desacoplados do sistema
 Conceitos do domínio não devem ser confundidos com conceitos
relacionados a tecnologia do software
Isolando o Domínio
Domain Driven Design – Aplicando Estratégias e Padrões 27
Arquitetura Domain Driven Design
Domain Driven Design – Aplicando Estratégias e Padrões 28
MVC x DDD
Domain Driven Design – Aplicando Estratégias e Padrões 29
 Também chamado de padrões
 Utilizados para representar o Modelo
 Foco na camada Domínio
 Os blocos são classificados em:
 Entidades (Entities)
 Objeto deValor (Value Objects)
 Serviços (Services)
Blocos de Construção
Domain Driven Design – Aplicando Estratégias e Padrões 30
 necessitam de uma identidade
 fio de continuidade
 elementos do domínio que
possuem ciclo de vida dentro de
um sistema
 Cliente se cadastra
 faz compras
 se torna inativo
 é excluído
 etc.
Entities
Domain Driven Design – Aplicando Estratégias e Padrões 31
 Objetos que carregam somente valores

 não possuem distinção de identidade
 As instâncias de Objetos deValores são
imutáveis, isto é, uma vez criados, seus
atributos internos não “deveriam” mais
ser modificados.
Value Objects
Domain Driven Design – Aplicando Estratégias e Padrões 32
 A operação representa um conceito do
domínio que não é parte natural de uma
Entity ouVO
 A interface é definida em termos de
outros elementos do modelo do domínio
 É importante ressaltar que Serviços não
guardam estado
 toda chamada a um mesmo serviço, dada
uma mesma pré-condição, deve retornar
sempre o mesmo resultado
Services
Domain Driven Design – Aplicando Estratégias e Padrões 33
• Serviço do aplicativo de transferência de fundos
• Digere as entradas (tais como uma solicitação XML)
• Envia mensagens para o serviço do domínio para complementação
• Espera a confirmação
• Decide enviar uma notificação através de um serviço de infra-estrutura
Aplicativo
• Serviço do domínio de transferência de fundos
• Interage com os objetos Conta e Livro Razão necessários, realizando
débitos e créditos adequadamente
• Fornece a confirmação do resultado (transferência permitida ou não, e
assim por diante)
Domínio
• Serviço de notificação de envio
• Envia e-mails, cartas e outros comunicados conforme instruído pelo
aplicativo
Infra-
estrutura
Exemplo - Dividindo Serviços em Camadas
Adaptado do livro Domain Driven Design, Eric Evans.
Domain Driven Design – Aplicando Estratégias e Padrões 34
 Utilização dos três padrões
 Agregados
 Fábricas
 Repositórios
 Os Agregados demarcam o escopo dentro do qual as invariantes tem que
ser mantidas em cada estágio do ciclo de vida
 As Fábricas e os Repositórios operam sobre os Agregados, encapsulando a
complexidade de transições específicas do ciclo de vida
Integridade e Complexidade
Domain Driven Design – Aplicando Estratégias e Padrões 35
Como manter a integridade do modelo com o
crescimento da complexidade?”
 Um Agregado é composto por um grupo
associado de Entities eValue Objects
 Agregados são tratado como uma só unidade
para efeitos de persistência
 Elegemos uma classe para servir de raiz do
Agregado
 As referências são permitidas apenas para a raiz
 A manipulação dos dados de uma das classes
que compõem o Agregado somente poderá ser
feita através da classe raiz
Agregado
Domain Driven Design – Aplicando Estratégias e Padrões 36
Agregado
Domain Driven Design – Aplicando Estratégias e Padrões 37
 Administram o ciclo de vida dos outros
objetos
 Entidades
 Objetos deValor
 Agregados
 Fornecem um mecanismo para encapsular o
armazenamento, recuperação e
comportamento de busca para obter coleções
de objetos.
 Em linguagens como Java e .NET, repositórios
são comumente implementados usando-se
frameworks como Hibernate ou Nhibernate
Repositório
Domain Driven Design – Aplicando Estratégias e Padrões 38
Repositório
Domain Driven Design – Aplicando Estratégias e Padrões 39
 São responsáveis pelo processo de criação
dos Agregados ou dos Objetos deValores
 Agregados podem ser relativamente
complexos de se criar e não é desejável
manter a lógica de criação destes Agregados
nas classes que o compõem
 As regras de criação são encapsuladas em
uma classe externa, a Fábrica
Fábrica
Domain Driven Design – Aplicando Estratégias e Padrões 40
Fábrica
Domain Driven Design – Aplicando Estratégias e Padrões 41
 Requisitos
 Corretores registram ofertas
 Sistema envia email marketing todos os dias pela manhã
 Sistema seleciona as ofertas do dia
 Cliente compra oferta
 Cliente paga oferta
 Sistema emite cupom ao final do dia
 Cliente utiliza cupom
 Parceiro baixa cupom
 Sistema paga o valor das vendas aos Parceiros
 Sistema paga comissão aos Corretores
Domain Driven Design – Aplicando Estratégias e Padrões 42
Exemplo – Compras Coletivas
Domain Driven Design – Aplicando Estratégias e Padrões 43
Draft - Compras Coletivas
DDD - Conclusões
 Promove alta coesão e baixo acoplamento.
 Torna fácil testar componentes de negócio.
 A lógica de negócio do domínio é isolada de non-domain e código de infra-
estrutura
 A adição/mudança de serviços não causa impacto no domínio ou em
outros serviços
 Todos os stakeholders falam uma mesma linguaguem (Ubiquitous Language)
Domain Driven Design – Aplicando Estratégias e Padrões 44
Domain Driven Design – Aplicando Estratégias e Padrões 45
Obrigado!
EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO
Rua São José 90, 2º andar
Esquina com Avenida Rio Branco
CEP 20010-020
Domain Driven Design – Aplicando Estratégias e Padrões 46

Mais conteúdo relacionado

Mais procurados

Domain-Driven-Design
 Domain-Driven-Design Domain-Driven-Design
Domain-Driven-Design
Wende Mendes
 
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
 
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
 
Bolovo - problema antigo de arquitetura de software - não use por aí
Bolovo - problema antigo de arquitetura de software - não use por aíBolovo - problema antigo de arquitetura de software - não use por aí
Bolovo - problema antigo de arquitetura de software - não use por aí
Priscila Mayumi
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
Jonatas Saraiva
 
Padroes de projetos gof
Padroes de projetos gofPadroes de projetos gof
Padroes de projetos gof
Yan Justino
 
Engenharia de Software Baseada em Componentes
Engenharia de Software Baseada em ComponentesEngenharia de Software Baseada em Componentes
Engenharia de Software Baseada em Componentes
elliando dias
 
Desenvolvimento baseado em componentes
Desenvolvimento baseado em componentesDesenvolvimento baseado em componentes
Desenvolvimento baseado em componentes
Dávisson Húdson Chaves Bernadete
 
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em ComponentesTCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
Juliano Tiago Rinaldi
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
Daniel Everling
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
elliando dias
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...
Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...
Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...
Anderson Kanegae Soares Rocha
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
Adriano Tavares
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
Vagner Santana
 
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCE
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCECOMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCE
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCE
Fernando S. de Paulo
 
Desenvolvendo Interfaces de Usuário Multiplataformas utilizando MDA
Desenvolvendo Interfaces de Usuário Multiplataformas utilizando MDADesenvolvendo Interfaces de Usuário Multiplataformas utilizando MDA
Desenvolvendo Interfaces de Usuário Multiplataformas utilizando MDA
Interaction Design Association Chapter São Paulo
 
Engenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em ComponentesEngenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em Componentes
igordsm
 
Alexandre Mattos, PMP
Alexandre Mattos, PMPAlexandre Mattos, PMP
Alexandre Mattos, PMP
mattosslideshare
 

Mais procurados (19)

Domain-Driven-Design
 Domain-Driven-Design Domain-Driven-Design
Domain-Driven-Design
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
 
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
 
Bolovo - problema antigo de arquitetura de software - não use por aí
Bolovo - problema antigo de arquitetura de software - não use por aíBolovo - problema antigo de arquitetura de software - não use por aí
Bolovo - problema antigo de arquitetura de software - não use por aí
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
 
Padroes de projetos gof
Padroes de projetos gofPadroes de projetos gof
Padroes de projetos gof
 
Engenharia de Software Baseada em Componentes
Engenharia de Software Baseada em ComponentesEngenharia de Software Baseada em Componentes
Engenharia de Software Baseada em Componentes
 
Desenvolvimento baseado em componentes
Desenvolvimento baseado em componentesDesenvolvimento baseado em componentes
Desenvolvimento baseado em componentes
 
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em ComponentesTCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...
Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...
Arquitetura de Software Baseada em Componentes: Um Estudo de Caso para o Cont...
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
 
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCE
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCECOMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCE
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCE
 
Desenvolvendo Interfaces de Usuário Multiplataformas utilizando MDA
Desenvolvendo Interfaces de Usuário Multiplataformas utilizando MDADesenvolvendo Interfaces de Usuário Multiplataformas utilizando MDA
Desenvolvendo Interfaces de Usuário Multiplataformas utilizando MDA
 
Engenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em ComponentesEngenharia De Software Baseada Em Componentes
Engenharia De Software Baseada Em Componentes
 
Alexandre Mattos, PMP
Alexandre Mattos, PMPAlexandre Mattos, PMP
Alexandre Mattos, PMP
 

Semelhante a Domain Driven Design - Aplicando estrategias e padrões

DDD
DDDDDD
O Archimate® como ferramenta de apoio para uso do TOGAF®
O Archimate® como ferramenta de apoio para uso do TOGAF® O Archimate® como ferramenta de apoio para uso do TOGAF®
O Archimate® como ferramenta de apoio para uso do TOGAF®
Blue Hawk - B&IT Management
 
Aula 06 projetos multimídia
Aula 06   projetos multimídiaAula 06   projetos multimídia
Aula 06 projetos multimídia
Fábio Costa
 
Aula 06 projetos multimídia
Aula 06   projetos multimídiaAula 06   projetos multimídia
Aula 06 projetos multimídia
Fábio Costa
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
Ítalo Bandeira
 
Domain Driven Design: como modelar uma aplicação em Node.js com DDD
Domain Driven Design: como modelar uma aplicação em Node.js com DDDDomain Driven Design: como modelar uma aplicação em Node.js com DDD
Domain Driven Design: como modelar uma aplicação em Node.js com DDD
Daniel Baptista Dias
 
Intranets - Portal corporativo CCEE - estudo de caso
Intranets - Portal corporativo CCEE - estudo de casoIntranets - Portal corporativo CCEE - estudo de caso
Intranets - Portal corporativo CCEE - estudo de caso
Suzana Ribeiro
 
Palestra papel do desenvolvedor no sucesso da empresa
Palestra papel do desenvolvedor no sucesso da empresaPalestra papel do desenvolvedor no sucesso da empresa
Palestra papel do desenvolvedor no sucesso da empresa
Henrique Nunes Bez Fontana
 
Macro Arquitetura de Software
Macro Arquitetura de SoftwareMacro Arquitetura de Software
Macro Arquitetura de Software
Edjalma Queiroz da Silva
 
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
FChico2
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
Graziella Bonizi
 
Rup e metodos ágies
Rup e metodos ágiesRup e metodos ágies
Rup e metodos ágies
Márcia Capellari
 
Arquitetura de-software
Arquitetura de-softwareArquitetura de-software
Arquitetura de-software
georginavieira1
 
Apostial i.h.c - apostila oficial
Apostial   i.h.c - apostila oficialApostial   i.h.c - apostila oficial
Apostial i.h.c - apostila oficial
Daniel Nunes
 
Ágil e Arquitetura-Os Opostos se Atraem
Ágil e Arquitetura-Os Opostos se AtraemÁgil e Arquitetura-Os Opostos se Atraem
Ágil e Arquitetura-Os Opostos se Atraem
Centus Consultoria
 
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDDisciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Rogerio P C do Nascimento
 
Quero ser analista de requisitos ou negócios. Por onde eu começo?
Quero ser analista de requisitos ou negócios. Por onde eu começo? Quero ser analista de requisitos ou negócios. Por onde eu começo?
Quero ser analista de requisitos ou negócios. Por onde eu começo?
Venícios Gustavo
 
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
 

Semelhante a Domain Driven Design - Aplicando estrategias e padrões (20)

DDD
DDDDDD
DDD
 
O Archimate® como ferramenta de apoio para uso do TOGAF®
O Archimate® como ferramenta de apoio para uso do TOGAF® O Archimate® como ferramenta de apoio para uso do TOGAF®
O Archimate® como ferramenta de apoio para uso do TOGAF®
 
Aula 06 projetos multimídia
Aula 06   projetos multimídiaAula 06   projetos multimídia
Aula 06 projetos multimídia
 
Aula 06 projetos multimídia
Aula 06   projetos multimídiaAula 06   projetos multimídia
Aula 06 projetos multimídia
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
 
Domain Driven Design: como modelar uma aplicação em Node.js com DDD
Domain Driven Design: como modelar uma aplicação em Node.js com DDDDomain Driven Design: como modelar uma aplicação em Node.js com DDD
Domain Driven Design: como modelar uma aplicação em Node.js com DDD
 
Intranets - Portal corporativo CCEE - estudo de caso
Intranets - Portal corporativo CCEE - estudo de casoIntranets - Portal corporativo CCEE - estudo de caso
Intranets - Portal corporativo CCEE - estudo de caso
 
Palestra papel do desenvolvedor no sucesso da empresa
Palestra papel do desenvolvedor no sucesso da empresaPalestra papel do desenvolvedor no sucesso da empresa
Palestra papel do desenvolvedor no sucesso da empresa
 
Macro Arquitetura de Software
Macro Arquitetura de SoftwareMacro Arquitetura de Software
Macro Arquitetura de Software
 
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
6_TI2007-Desenv_SI_e_DFD_v2.5.pdf
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
 
Rup e metodos ágies
Rup e metodos ágiesRup e metodos ágies
Rup e metodos ágies
 
Arquitetura de-software
Arquitetura de-softwareArquitetura de-software
Arquitetura de-software
 
Apostial i.h.c - apostila oficial
Apostial   i.h.c - apostila oficialApostial   i.h.c - apostila oficial
Apostial i.h.c - apostila oficial
 
Ágil e Arquitetura-Os Opostos se Atraem
Ágil e Arquitetura-Os Opostos se AtraemÁgil e Arquitetura-Os Opostos se Atraem
Ágil e Arquitetura-Os Opostos se Atraem
 
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDDisciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
 
Quero ser analista de requisitos ou negócios. Por onde eu começo?
Quero ser analista de requisitos ou negócios. Por onde eu começo? Quero ser analista de requisitos ou negócios. Por onde eu começo?
Quero ser analista de requisitos ou negócios. Por onde eu começo?
 
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 ...
 

Domain Driven Design - Aplicando estrategias e padrões

  • 1. Domain Driven Design Aplicando Estratégias e Padrões João Paulo Santos, MSc 1
  • 2.  Formação  Mestre em Sistemas de Informação – UNIRIO  Linha de pesquisa: Sistemas de Apoio a Negócios  Pós-Graduado em Gerenciamento de Projetos – FGV  Bacharel em Informática - UERJ  Coordenador Pedagógico do MIT em Arquitetura de Software  Professor de Graduação e Pós-Graduação  Infnet, Decision (FGV-POA), UERJ  Experiência de Mercado  + de 15 anos com Integração de Sistemas,Arquitetura de Software,Análise e Desenvolvimento de Sistemas  Arquiteto de Sistemas focado na definição dos componentes de software e integração das soluções da Gestora de Recursos do Banco do Brasil. Possui mais de 15 anos de experiência atuando nas áreas de Integração de Sistemas,Arquitetura de Software,Análise e Desenvolvimento de Sistemas Domain Driven Design – Aplicando Estratégias e Padrões 2 Quem sou...
  • 3.  Abordar sucintamente os principais conceitos de Domain Driven Design.  Discutir e demonstrar a aplicação de estratégias e padrões na elaboração de um modelo de domínio. Objetivos Domain Driven Design – Aplicando Estratégias e Padrões 3
  • 4.  Estudantes de graduação e pós-graduação nas áreas de sistemas de software  Analistas e desenvolvedores de software  Arquitetos de software Publico alvo Domain Driven Design – Aplicando Estratégias e Padrões 4
  • 5.  Contextualização : modelo, domínio e modelo de domínio  Problemas com a orientação a objetos  Conceitos básicos de DDD  Técnicas para modelagem de domínio  Padrões de domínio Agenda Domain Driven Design – Aplicando Estratégias e Padrões 5
  • 6. Domain Driven Design – Aplicando Estratégias e Padrões 6 O que é isso?
  • 7.  É uma simplificação  Representa algum aspecto da realidade com uma ideia que seja de interesse  Interpretação da realidade que destaca os aspectos relevantes para resolver o problema  Ignora os detalhes “estranhos” Domain Driven Design – Aplicando Estratégias e Padrões 7 Modelo
  • 8.  Área de conhecimento  Área de interesse dos usuários  Exemplo:  Domínios do mundo físico:  Programa de reserva de passagens aéreas – pessoas reais entrando em aeronaves reais  Domínio intangível:  Programa de contabilidade – dinheiro e as finanças Domínio Domain Driven Design – Aplicando Estratégias e Padrões 8
  • 9. “Os modelos de domínios podem trazer grandes vantagens para o controle do desenvolvimento de softwares – sejam quais forem a linguagem e o ambiente em que eles sejam implementados” Martin Fowler Domain Driven Design – Aplicando Estratégias e Padrões 9
  • 10.  Ferramenta para atacar a sobrecarga de informação e complexidade de um domínio  É uma forma de abstração rigorosamente organizada e seletiva do conhecimento dos especialistas  Dá sentido as informações  Concentra-se em um problema Modelo de Domínio Domain Driven Design – Aplicando Estratégias e Padrões 10
  • 11.  Um diagrama específico  Uma questão de se criar um modelo o mais realista possível e sim é uma criação artificial  Simplesmente a criação de um mecanismo de software que forneça os resultados necessários Modelo de Domínio Não é Domain Driven Design – Aplicando Estratégias e Padrões 11
  • 12.  O modelo e o coração do design dão forma um ao outro  O modelo é a “espinha dorsal” de uma linguagem utilizada por todos os membros da equipe  O modelo é um conhecimento destilado Modelo de Domínio é útil para: Domain Driven Design – Aplicando Estratégias e Padrões 12
  • 13. Lembra? Domain Driven Design – Aplicando Estratégias e Padrões 13 1980 1986 1969 - Smaltalk
  • 14.  Foco em Arquitetura e Design (independente do domínio)  Ferramentas e frameworks têm, silenciosamente, deturpado os valores originais da POO Por que a POO não é suficiente? Domain Driven Design – Aplicando Estratégias e Padrões 14 “Falta disciplina para modelagem de domínios grandes e complexos”
  • 15.  O foco principal para construção de sistemas deveria ser no domínio e na lógica do negócio  O design de um domínio complexo deveria ser baseado em um modelo Por que a POO não é suficiente? Domain Driven Design – Aplicando Estratégias e Padrões 15
  • 16. Solução... Domain Driven Design – Aplicando Estratégias e Padrões 16
  • 17.  É um conjunto de técnicas comprovadas de modelagem notadamente para aplicações complexas  É um conjunto de princípios e práticas que dão suporte ao processo de desenvolvimento  É um conjunto de padrões que formam um visão coesa e coerente do modelo de domínio  É um conjunto de estratégias que permitem escalar aplicações em tamanho e complexidade Domain Driven Design Domain Driven Design – Aplicando Estratégias e Padrões 17
  • 18.  O time e os experts no domínio trabalham de forma contínua (e iterativa) refinando o modelo e buscando melhor compreensão do problema a ser solucionado  Os canais de comunicação entre os domain experts e o time devem estar sempre abertos DDD e Colaboração Domain Driven Design – Aplicando Estratégias e Padrões 18
  • 19.  Modelo e Design devem evoluir em sincronia – desenvolvimento contínuo  O código é a última (e mais importante) forma de expressão do modelo  Artefatos intermediários servem basicamente como documentos temporários Modelo de Domínio e Design Domain Driven Design – Aplicando Estratégias e Padrões 19
  • 20. Domain Driven Design – Aplicando Estratégias e Padrões 20 Como entender o negócio e modelar um domínio corretamente?
  • 21. Desenvolvedores Especialista do domínio  Foco em classes, métodos, algoritmos, padrões  Comparações entre conceitos da vida real e artefatos de programação  Criação de classes de objeto e suas relações com o modelo  Pensam em termos de encapsulamento, herança e polimorfismo  Foco em suas competências específicas  Não conhecem sobre desenvolvimento de software e nem técnicas de modelagem  Não tem idéia do que é um framework, persistência e em muitos casos nem sobre bancos de dados Domain Driven Design – Aplicando Estratégias e Padrões 21 A necessidade de uma linguagem comum
  • 22.  Os especialistas do domínio conhecem:  Ordem de negócio  Ações  Stop Loss  Pu,Var,Tir, PL  Fluxo de Caixa  Utilizam um jargão próprio que não é facilmente compreendido pelos membros da equipe técnica  A equipe técnica também possui o seu próprio jargão:  Query, SQL, SGBD  Patterns  MaquinaVirtual Exemplo – Mercado Financeiro Domain Driven Design – Aplicando Estratégias e Padrões 22
  • 23.  A Comunicação é fundamental para o sucesso do projeto  Se um diz algo e os outros não entendem, ou pior, entendem em outra conotação, quais são as chances de sucesso deste projeto? Problemas de Comunicação Domain Driven Design – Aplicando Estratégias e Padrões 23
  • 24. Precisamos falar a mesma linguagem Domain Driven Design – Aplicando Estratégias e Padrões 24
  • 25. Linguagem Ubíqua  Conecta-se a todas as partes do design  Define premissas e conceitos  Leva semanas e até meses para tomar forma em projetos de grande complexidade  Os especialistas devem atentar para os termos que transmitam o adequado conhecimento do domínio  Desenvolvedores devem atentar para eventuais ambigüidades ou incoerência Domain Driven Design – Aplicando Estratégias e Padrões 25
  • 26.  Linguagem Ubíqua viabiliza a elaboração do modelo de domínio  Profissionais que modelam o domínio também codificam o software  Programadores devem se sentir também responsáveis pelo modelo, caso contrário não haverá relação do código com o modelo  Processo de maturação contínuo Linguagem Ubíqua – Modelo de Domínio Domain Driven Design – Aplicando Estratégias e Padrões 26
  • 27.  Resolução dos problemas do domínio é realizada por uma pequena parte do sistema  Os elementos do domínio devem ser visto como um sistema  Os objetos do domínio devem estar desacoplados do sistema  Conceitos do domínio não devem ser confundidos com conceitos relacionados a tecnologia do software Isolando o Domínio Domain Driven Design – Aplicando Estratégias e Padrões 27
  • 28. Arquitetura Domain Driven Design Domain Driven Design – Aplicando Estratégias e Padrões 28
  • 29. MVC x DDD Domain Driven Design – Aplicando Estratégias e Padrões 29
  • 30.  Também chamado de padrões  Utilizados para representar o Modelo  Foco na camada Domínio  Os blocos são classificados em:  Entidades (Entities)  Objeto deValor (Value Objects)  Serviços (Services) Blocos de Construção Domain Driven Design – Aplicando Estratégias e Padrões 30
  • 31.  necessitam de uma identidade  fio de continuidade  elementos do domínio que possuem ciclo de vida dentro de um sistema  Cliente se cadastra  faz compras  se torna inativo  é excluído  etc. Entities Domain Driven Design – Aplicando Estratégias e Padrões 31
  • 32.  Objetos que carregam somente valores   não possuem distinção de identidade  As instâncias de Objetos deValores são imutáveis, isto é, uma vez criados, seus atributos internos não “deveriam” mais ser modificados. Value Objects Domain Driven Design – Aplicando Estratégias e Padrões 32
  • 33.  A operação representa um conceito do domínio que não é parte natural de uma Entity ouVO  A interface é definida em termos de outros elementos do modelo do domínio  É importante ressaltar que Serviços não guardam estado  toda chamada a um mesmo serviço, dada uma mesma pré-condição, deve retornar sempre o mesmo resultado Services Domain Driven Design – Aplicando Estratégias e Padrões 33
  • 34. • Serviço do aplicativo de transferência de fundos • Digere as entradas (tais como uma solicitação XML) • Envia mensagens para o serviço do domínio para complementação • Espera a confirmação • Decide enviar uma notificação através de um serviço de infra-estrutura Aplicativo • Serviço do domínio de transferência de fundos • Interage com os objetos Conta e Livro Razão necessários, realizando débitos e créditos adequadamente • Fornece a confirmação do resultado (transferência permitida ou não, e assim por diante) Domínio • Serviço de notificação de envio • Envia e-mails, cartas e outros comunicados conforme instruído pelo aplicativo Infra- estrutura Exemplo - Dividindo Serviços em Camadas Adaptado do livro Domain Driven Design, Eric Evans. Domain Driven Design – Aplicando Estratégias e Padrões 34
  • 35.  Utilização dos três padrões  Agregados  Fábricas  Repositórios  Os Agregados demarcam o escopo dentro do qual as invariantes tem que ser mantidas em cada estágio do ciclo de vida  As Fábricas e os Repositórios operam sobre os Agregados, encapsulando a complexidade de transições específicas do ciclo de vida Integridade e Complexidade Domain Driven Design – Aplicando Estratégias e Padrões 35 Como manter a integridade do modelo com o crescimento da complexidade?”
  • 36.  Um Agregado é composto por um grupo associado de Entities eValue Objects  Agregados são tratado como uma só unidade para efeitos de persistência  Elegemos uma classe para servir de raiz do Agregado  As referências são permitidas apenas para a raiz  A manipulação dos dados de uma das classes que compõem o Agregado somente poderá ser feita através da classe raiz Agregado Domain Driven Design – Aplicando Estratégias e Padrões 36
  • 37. Agregado Domain Driven Design – Aplicando Estratégias e Padrões 37
  • 38.  Administram o ciclo de vida dos outros objetos  Entidades  Objetos deValor  Agregados  Fornecem um mecanismo para encapsular o armazenamento, recuperação e comportamento de busca para obter coleções de objetos.  Em linguagens como Java e .NET, repositórios são comumente implementados usando-se frameworks como Hibernate ou Nhibernate Repositório Domain Driven Design – Aplicando Estratégias e Padrões 38
  • 39. Repositório Domain Driven Design – Aplicando Estratégias e Padrões 39
  • 40.  São responsáveis pelo processo de criação dos Agregados ou dos Objetos deValores  Agregados podem ser relativamente complexos de se criar e não é desejável manter a lógica de criação destes Agregados nas classes que o compõem  As regras de criação são encapsuladas em uma classe externa, a Fábrica Fábrica Domain Driven Design – Aplicando Estratégias e Padrões 40
  • 41. Fábrica Domain Driven Design – Aplicando Estratégias e Padrões 41
  • 42.  Requisitos  Corretores registram ofertas  Sistema envia email marketing todos os dias pela manhã  Sistema seleciona as ofertas do dia  Cliente compra oferta  Cliente paga oferta  Sistema emite cupom ao final do dia  Cliente utiliza cupom  Parceiro baixa cupom  Sistema paga o valor das vendas aos Parceiros  Sistema paga comissão aos Corretores Domain Driven Design – Aplicando Estratégias e Padrões 42 Exemplo – Compras Coletivas
  • 43. Domain Driven Design – Aplicando Estratégias e Padrões 43 Draft - Compras Coletivas
  • 44. DDD - Conclusões  Promove alta coesão e baixo acoplamento.  Torna fácil testar componentes de negócio.  A lógica de negócio do domínio é isolada de non-domain e código de infra- estrutura  A adição/mudança de serviços não causa impacto no domínio ou em outros serviços  Todos os stakeholders falam uma mesma linguaguem (Ubiquitous Language) Domain Driven Design – Aplicando Estratégias e Padrões 44
  • 45. Domain Driven Design – Aplicando Estratégias e Padrões 45 Obrigado!
  • 46. EDUCAÇÃO SUPERIOR ORIENTADA AO MERCADO Rua São José 90, 2º andar Esquina com Avenida Rio Branco CEP 20010-020 Domain Driven Design – Aplicando Estratégias e Padrões 46