domain driven design

Rodolfo Signorelli Spalenza @rodolfospalenza

[email protected]

DOMAIN DRIVEN DESIGN UFES

CIÊNCIA DA COMPUTAÇÃO – 2011/2

CIÊNCIA DA COMPUTAÇÃO -‐ UFES 1

DDD – DOMAIN DRIVEN DESIGN



Camadas

Orientação ao Objetos

ORM

Linguagens Dinâmicas Agilidade

Injeção de Dependência

POJO

REST DDD



FUTURO



DISCAGEM DIRETA A DISTÂNCIA



“DDD é uma abordagem para desenvolvimento

de soWware.”



BLA, BLA, BLA...

ERIC EVANS

FOCO DO DDD


FOCO DO DDD


FOCO NO DOMÍNIO DO PROBLEMA

DDD – PREMISSAS


ERIC EVANS

Para maioria dos projetos de soWware o foco deve ser no domínio e na lógica do domínio.

Desenhos complexos devem ser baseados em um modelo.

DOMÍNIO


ÁREA DE CONHECIMENTO DO SOFTWARE

MODELO


?

MODELO


CHINA MUNDO

NÃO PRECISA SER IMPECAVELMENTE REALISTA

MODELO


MAPA MUNDI – MODELO POLÍTICO

MODELO SÃO BASEADOS EM ABSTRAÇÕES

MODELO


MODELO


GOOGLE MAPS

MODELO – RESUMINDO

•  Modelos são abstrações, isto é, o que não for interessante para a solução do problema não deve pertencer ao modelo.

•  Modelos deve reflekr código e, o código, deve reflekr o modelo.

•  Se a quankdade de informações apresentadas no modelo for suficiente, o modelo está bom.

•  Não há padrão para um modelo. •  SIMPLICIDADE.




MODELO

FÁBRICA

OBJETOS DE VALOR

ENTIDADES REPOSITÓRIO

SERVIÇOS

LINGUAGEM UBÍQUA


•  Ubíqua quer dizer estar em todo lugar.

•  É reflekda no modelo. •  A linguagem vem do business expert.

•  Falada por todo o kme.

LINGUAGEM UBÍQUA

Analista de Negócio

Analista de

Sistema

Desenvolvedor

Arquiteto


CAMADAS


VERIFIQUE AS RESPONSABILIDADES DAS SUAS CAMADAS

DDD – CAMADAS


A camada de domínio é o coração de um soWware

de negócio.

POCOS


BOM E VELHO OBJETO DO CLR

ENTIDADES


EnZdades têm significado para o domínio.

EnZdades possuem idenkdade para o domínio.

IDENTIDADE PARA O DOMÍNIO ≠

IDENTIDADE PARA O DB

OBJETOS DE VALOR


Objetos de valor não tem Idenkdade para o negócio.

São reconhecidos pelos seus atributos. Frequentemente são imutáveis.

AGREGAÇÃO


Agregação é um conjunto de enkdades e objetos de valores que se relacionam no domínio.

Toda agregação tem uma raiz para controlar o acesso.

Define fronteiras para o domínio.

AGREGAÇÃO


AGREGAÇÃO


TODA ATUALIZAÇÃO

DEVE PASSA PELA RAIZ

NÃO HÁ REFERÊNCIAS DIRETAS PARA

OBJETOS CONTIDOS NO INTERIOR DA AGRAGAÇÃO

UMA EXCLUSÃO DEVE APAGAR TODOS OS OBJETOS DA AGRAGAÇÃO

OS OBJETOS QUE DEVEM

ESPECIFICAR AS REGRAS DE NEGÓCIO

SERVIÇOS


Serviços resolvem problemas de negócio.

Não são enkdades nem objetos de valor.

É comum ter somente um método e nenhum atributo.

FÁBRICA


Fábricas criam objetos complexos do domínio.

Um carro não anda com sua fábrica.

FÁBRICA


BOA PRÁTRICA

?

REPOSITÓRIOS


Repositórios fantasiam dados em memória.

Para o consumidor não há diferença onde está o objeto.

São responsáveis por persiskr e destruir os objetos.

CICLO DE VIDA DOS OBJETOS


FÁBRICAS CRIAM

REPOSITÓRIOS RECUPERAM

REPOSITÓRIOS ALTERAM

REPOSITÓRIOS DESTROEM

PROJETO – CASCATA


ANÁLISE

PROJETO

IMPLEMENTAÇÃO

VERIFICAÇÃO

MANUTENÇÃO

PROJETO – ÁGIL


Projeto que uklizam DDD são capazes de aceitas as mudanças.

Feedback constante.

REFERÊNCIAS

[1] – Eric Evans, Domain Driven Design – Atacando as Complexidades no Coração do SoWware. [2] – Leandro Daniel, htp://www.leandrodaniel.com/reverb/category/DDD.aspx


domain driven design

Education