O documento apresenta os conceitos e arquitetura do Design Orientado a Domínio (DDD). Ele explica que DDD é uma abordagem de desenvolvimento de software focada nas regras de negócio e no domínio, não nos bancos de dados. O documento também descreve artefatos como entidades, objetos de valor, agregações, serviços e repositórios.

1. André Zanatta Borgonovo

2. 1. Introdução
2. Conceitos
3. Arquitetura
4. Artefatos de Domínio (exemplos em C#)
5. Aplicação e Processo

3. O que é e não é DDD

4.  Algo que resolve tudo
 Sempre a melhor solução
 Um caminho fácil para seguir
“Everything should be made as simple as
possible, but not simpler.”
Albert Einsten

5.  Design (Projeto) Orientado ao Domínio
 Uma abordagem de desenvolvimento de
software
 Uma metodologia de arquitetura para a
evolução de um sistema alinhado às
necessidades do negócio
 Software OO feito da maneira correta (Jak
Charlton, DDD Step-by-step)

6. “Atacando as Complexidades
no Coração do Software”
Eric Evans

7. 1. Corrige a arquitetura do projeto. Diminui a
complexidade e aumenta a manutenibilidade
da aplicação
2. Você faz software para durar
3. Quem deve se preocupar com DDD?
4. “Durabilidade” do DDD
5. Outros *DDs

8.  O foco é no domínio, são as regras de
negócio, os comportamentos
 O foco NÃO é trabalhar com o banco de
dados
 Software de negócios com regras complexas
“Domínio é a área de
conhecimento do software”

9.  O foco deve ser o domínio e a lógica do domínio
 Projetos complexos devem ser baseados em um
modelo
 Iniciar uma colaboração criativa entre a área
técnica e os domain experts para iterativamente
estarem mais perto do coração conceitual do
problema

10. Linguagem ubíqua, contextos
delimitados, módulos, domain
expert, domínio e modelo

11. Ubiquitous = Ubíquo = Está em todo lugar
Linguagem ubíqua é a linguagem usada pelo:
Business expert = Domain expert = Product owner (Scrum)
• O time inteiro utiliza a mesma linguagem
• Não utilizar linguagem técnica para falar com o Domain
expert
• Proximidade entre o Domain expert e os desenvolvedores
• A análise realizada deve ser natural para o Domain expert
• É importante que todos do projeto conheçam o domínio
• Substantivos = Classes
• Verbos = Métodos, Serviços e etc.

12.  É relativo. Não tem padrão. Baseado em
abstrações.
 É usado para resolver problemas. Tem que
ser útil.
 Deve estar atualizado. Deve refletir no
código.
 Representa o domínio.
Use POCOs (Plain Old CLR Objects)

13. Pode ser assim: Ferramenta ajuda a manter
seu modelo atualizado
…Ou assim:

14. Apresentação
Aplicação
Domínio
Infraestrutura

15. • Camadas devem estar separadas
• Separação de responsabilidades
• Arquitetura flexível
Layers X Tiers
Layers: Camadas lógicas
Tiers: “Projetos do Visual Studio”

17. Usuário pode ser outro sistema.
Camada de apresentação

18. Coordena as atividades (workflow)
da aplicação. Transformação de
objetos (DTOs).
Transação, auditoria e segurança.

19. “A camada de domínio é o
coração do software”

20. Persistência de dados.
Conceitos transversais:
autenticação, autorização,
cache, gerenciamento de
exceções, log, validação.

21. Usuário pode ser outro sistema.
Camada de apresentação
Coordena as atividades (workflow)
da aplicação. Transformação de
objetos (DTOs). Transação,
auditoria e segurança.
“A camada de domínio é o
coração do software”
Persistência de dados.
Conceitos transversais:
autenticação, autorização,
cache, gerenciamento de
exceções, log, validação.

23. Entidades, objetos de valor,
agregações, fábricas, serviços
e repositórios

24.  Objetos que tem significado no Domínio
 Tem identidade
 Exemplos:
◦ Cliente
◦ Carro
◦ Produto

25. Abstração para entidades
Entidade simples

26.  Não tem identidade para o negócio
 São reconhecidos pelos seus atributos
 Atributo diferente = objeto diferente
 Imutáveis
 Exemplos:
◦ Cores
◦ Coordenadas
◦ Endereços

27. Abstração para
objetos de valor
Objeto de valor simples

30.  Reúne entidades e objetos de valor que
fazem sentido no domínio
 Raiz da agregação (Aggregate Root)
 Regras de agregações:
◦ Todas as atualizações passam pela raiz
◦ Todas as referencias obtidas para os objetos
recupera-se pela raiz
◦ Exclusão apaga todos os filhos da agregação
◦ Regras de negócio são garantidas pela raiz

33.  Resolvem problemas de negócio, mas não
são entidades ou objetos de valor
 Um bom serviço tem três caracteristicas:
1. A operação é relacionada a um conceito do
domínio que não é naturalmente parte de uma
entidade ou objeto de valor
2. A interface é definida baseada em outros objetos
do modelo do dominio
3. A operação é Stateless

35.  Criam objetos de negócio
 É responsabilidade de um objeto construir a
si mesmo?
 Regras complexas para construção
 Fábrica cria objetos consistentes

37.  “Não tem banco de dados”
 Persistence Ignorance
 Representam uma lista de itens em memória
 Não tem lógica de negócio. No máximo valida
consistência do objeto. Assim como guardou
deve ser recuperado
 São especificados para Agregações, não para
Entidades

38. Abstração para repositórios
Repositório simples

39. Exemplo de
implementação de
repositório com Entity
Framework

40.  Fábricas criam os objetos
 Repositórios:
◦ Inserem;
◦ Recuperam;
◦ Alteram;
◦ Destroem os objetos.

41. Go DDD, go Agile!

42.  Regras de negócio complexas
 Atenção:
◦ Arquitetos geralmente trabalham em projetos
complexos
◦ Projetos simples podem se tornar importantes para
o negócio da empresa no futuro
Use DDD na maior parte dos softwares que tem
regra de negócio

43.  Não para o desenvolvimento em cascata
(Waterfall). Recomendado desenvolvimento
ágil
 DDD aceita as mudanças. Software se torna
altamente adaptável
 Proximidade e contato com o Domain expert

46. Autor
André Zanatta Borgonovo
azborgonovo@gmail.com
@azborgonovo
Links Recomendados
http://domaindrivendesign.org/
http://microsoftnlayerapp.codeplex.com/
http://blog.lambda3.com.br/