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