domain-driven-design

Domain Driven Design (DDD)

Wende Mendes Higino

Email: wende.mendes@bluesoft.com.br

Objetivo

O que o DDD pode fazer por você

Visão de futuroPorque os arquitetos de software devem se preocupar com o DDD ?

Temos que fazer software para durar

O que é DDD ?

“ É uma abordagem para desenvolvimento de software ”

Qual é o foco do DDD ?

Banco de dados ?

Focado no domínio

Principais premissas do (DDD)

“ Para a maioria dos projetos de software o foco

principal deve ser no domínio e na lógica do

domínio ”

“ Desenhos complexos de domínio devem ser

baseados em modelos ”

Domínio ?

Domínio:

- Área de conhecimento do software

Exemplo: domínio do software de uma farmácia: - controle de preço, estoque, etc.

Modelo ?

O mundo

O mundo

Não precisa ser impecavelmente realista

- Modelo são baseados em abstrações.

- É uma idéia e deixa um monte de detalhes de fora.

Modelos ?

O mundo

Excesso de informações atrapalha

Brasil

São Paulo

BlueSoft

BlueSoft

Usado para resolver problemas

Recapitulando:

* Modelos são abstrações

- O que não interessa fica de fora

- O modelo deve refletir no código ou são irrelevantes

- O modelo deve representar o seu domínio

Não há padrão para um modelo

Pode ser assim:

Ou assim:

Compõe o modelo...

Ubiquitous Language:

- Vem dos business experts

- É refletida no modelo

- É refletida no código

- É falada pelo time

Não

- Tabela

- Classe

- método

- String

- Banco de dados

Sim

- Carga

- Conta corrente

- Agendamento de horários

- Deposito bancário

- Realizar matricula

Ouça business experts

É ele que entende do negócio.

É ele que conhece o problema, não você

Distância dos desenvolvedores e o contexto do domínio

- Camadas devem fazer sentido.“ verifique suas responsabilidades ”

- As camadas tem que ter separação

Camadas do DDD

"Esta camada é o coração de um software de negócio”

(Eric Evans)

Conceitos do DDD

Entidade: São objetos que tem significado no domínio

Entidade: possuem identidades

- Objetos de valor não tem identidade para o negócio

- São reconhecidos por seus atributos

- Geralmente são imutáveis

Azul

Verde

Vermelho

Exemplo:

Objetos de Valor

- Reúnem entidades e objetos de valor de maneira que faça sentido para o negócio

- Toda agregação tem uma raiz

Agregações

Algumas regras:

Serviços

- Serviços resolvem problemas de negócio, mas não são entidades e nem objetos de valor

- Se meu serviço precisar retornar algum objeto, este objeto tem que estar no meu domínio

Serviços

Exemplo :

Factories

- Criam objetos

- Objetos devem ser criados consistentes

Factories

Exemplo :

Repositórios

- Responsáveis por persistir e destruir os objetos

- Responsáveis por guardar e recuperar objetos

- Falar a língua do negócio

* Vai ter métodos:- obter por data

- obter por cpf- obter por vencimento

Exemplo de um projeto

Exemplo de um projeto

Camadas do domínio

Camadas do domínio

Camadas do domínio

Ciclo de vida de um objeto para o DDD:

- Factories criam objetos

Ciclo de vida de um objeto para o DDD:

- Factories criam objetos

- Repositórios recuperam objetos

Ciclo de vida de um objeto para o DDD:

- Factories criam objetos

- Repositórios recuperam objetos

- Repositórios alteram objetos

Ciclo de vida de um objeto para o DDD:

- Factories criam objetos

- Repositórios recuperam objetos

- Repositórios alteram objetos

- Repositórios destroem objetos

Ciclo de vida:

- Factories criam objetos

- Repositórios recuperam objetos

- Repositórios alteram objetos

- Repositórios destroem objetos

Funciona assim ?

Funciona assim ?

Feedback é fundamental.

O tempo todo !

Recomendação

- O DDD aceita mudanças

- Não brigue com elas

Recomendações:

“ O foco são os projetos com regras de negócio complexas ”

“ Quando as empresas fam que o projeto é simples, comece a tomar cuidado, pois eles crescem ”

“ Comece com projetos pequenos para aprender ”

Obrigado

Bibliografia