ddd - domain driven design
DESCRIPTION
Apresentação sobre DDD - Domain Driven Design na pós graduação em Engenharia de Software Centrada em Métodos ÁgieisTRANSCRIPT
DDD – DOMAIN DRIVEN DESIGN
Domain-Driven Design
Domain-Driven Design não é uma tecnologia ou metodologia, mas sim uma abordagem de design de software disciplinada que reúne um conjunto de conceitos, técnicas e princípios com foco no domínio e na lógica do domínio para criar um domain model.
Domain-Driven Design
O modelo pode ser expresso de várias formas, como uma apresentação em PowerPoint, diagramas em UML, rascunho de papel, peças de Lego, o mesmo o código da aplicação.
Padrões
É uma regra de três partes que expressa a relação entre um contexto1, um problema² e uma solução³.
O que é DDD?
Livro de Eric Evans (2004) Padrões Boas práticas Experiência
Foco: Domínio
Alinhamento com negócio Isolamento entre domínios Reutilização Mínimo acoplamento Independente de tecnologia
DDD
A volta da Orientação a Objetos?
Padrões no DDD
[Contexto] [Discussão do problema]
Resumo do problema Discussão da solução
Por esta razãoResumo da solução
Consequências, implementação, exemplos. [Contexto resultante]
DDDColocando o modelo de
domínio para funcionar
Blocos de construção do
MDD
Refatorando para
compreender profundament
e o modelo
Projeto estratégico
Colocando o modelo de domínio para funcionar
Linguagem Ubíqua
Model Driven Design
Domínio
Modelo
DesignDesenvolvedores
perdidos e tecnologia
inadequada
Sofware não serve para o
domínio
Guia
Aperfeiçoa
Refatoração
Blocos de Construção do
Model
Driven
Design
Arquitetura em Camadas
Entidades
Objetos de Valores
Pra quem não precisa de identidade; Imutáveis; Descrevem coisas; Ciclo de vida rápido; Exemplos: strings, números, cores.
Agregados
Entidade
Objeto de Valor
EntidadeObjeto de
Valor
Agregado
Fábricas
Quando construir (Agregados) for complexo;
Devem ser sempre abstratas; Não fazem parte do modelo, mas do
domínio.
Serviços
A operaçao não faz parte de nenhuma Entidade ou Objeto de Valor;
Interface fala a língua do Domínio; Sem estado.
Módulos
Agrupe conceitos do modelo, não código;
Baixo acoplamento / alta coesão; Nomes da Linguagem Ubíqua.
Módulos
Módulo = Capítulo
Módulo = Capítulo
Módulo = Capítulo
Módulo = Capítulo
Módulo = Capítulo
Módulo = Capítulo
Modelo = História
Repositórios
Código ClienteRepositório
Agregados
Agregados
Agregados
Entidades
Entidades
Entidades
Busc
a
Cria
Entidade
Remov
er
Linguagem Ubíqua
Model Driven Design
Serviços Objetos
Valor
Entidades
Módulos
Agregados
Expressa modelo como
Encapsula com
Mantém Integridade com
Repositórios
Acessa com
Acessa com
Fábricas Encapsula
com
Encapsula com
Refatorando para compreender
profundamente o modelo
Padrões para refinar o modelo
Interfaces de intenção revelada
Eu faço exatamente
isso. Não precisa se preocupar
como.
Padrões para refinar o modelo
Funções sem efeitos colaterais
Colocar tudo o que for possível em funções, principalmente em cálculos complexos
Onde não der, usar comandos que fazem poucas operações e não retornam objetos do domínio
Padrões para refinar o modelo
Asserções
Testes de unidade; Usar facilidades da linguagem; Testam o comportamento dos comandos.
Linguagem Ubíqua
Model Driven Design
Interfaces de
Intenção Revelada
Funções sem
Efeitos Colaterai
s
Asserções
Expressa modelo através
de
Torna efeitos
colateraisexplícitos
com
desenhadas
usando
cria seguras
e simples
Torna
composiç
ão segura
Projeto Estratégico
Projeto Estratégico - Padrões
Contexto Delimitado
As células existem porque sua membrana define o que está dentro ou fora e determina o que pode entrar.
Projeto Estratégico - Padrões
Integração contínua Fazer figura próximo slide
Integração Contínua
Testes automatizados; Processo de build automático; Sincronização diária; Relatórios.
Novo Elemento do
Modelo
Codificação
Im-ple-
men-tação
Testes
Projeto Estratégico - Padrões
Mapa do Contexto
Projeto Estratégico - Padrões
Núcleo Compartilhado É mais difícil fazer mudanças; Evita (mas não elimina) duplicações.
Projeto Estratégico - Padrões
Produtor – Consumidor
Testes automatizados Cliente - Fornecedor
Projeto Estratégico - Padrões
Conformista
Time fornecedor não interesse em ajudar; Tira complexidade de tradução entre
contextos; Mesma linguagem ubíqua; Parecido com Núcleo Compartilhado , mas
cliente não tem poder de modificação.
Projeto Estratégico - Padrões
Camada Anti-Corrupção
Projeto Estratégico - Padrões
Caminhos separados
Quando integrar custa caro e o benefício é pequeno;
Contexto delimitado que não tem nenhuma conexão com os outros.
Resumindo
Trabalhando com um modelo; Blocos de construção; Refatorando e evoluindo; Refinando, destilando.
Refinando um modelo
Isso Não é Tudo
DDD
Os padrões citados são apenas alguns dos descritos em Domain Driven Design. DDD é uma forma de desenvolver software que, por estar ligado a boas práticas de Orientação a Objetos, tem muito a ver com desenvolvimento ágil.
A própria idéia de Padrões, que promove eficácia na comunicação, é um dos valores pregados pelos agilistas.
São técnicas que levarão ao desenvolvimento de serviços de qualidade, sistemas seguros e fáceis de dar manutenção, levando, consequentemente, à satisfação dos seus clientes com a rapidez que o mercado de hoje exige.
Vantagens de adotar o DDD
Quanto mais próximo você está do negócio, menos sofre com mudanças
O entendimento do desenvolvedor sobre o negócio, evitando erros e ajudando no negócio em si, questionando e sugerindo otimizações.
Código menos acoplado e mais coeso.
Conclusão
Procure utilizar DDD em aplicações com domínios complexos
Linguagem Ubíqua e MDD são o cerne da DDD
Não se apegue à rigidez conceitual, e claro, não lute contra os frameworks.
Referências
Evans, Eric. Domain Driven Design. Addison – Wesley, 2004.
http://www.infoq.com/resource/minibooks/domain-driven-design-quickly/en/pdf/DomainDrivenDesignQuicklyOnline.pdf
http://vimeo.com/3545313