Your SlideShare is downloading. ×
Introdução ao DDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Introdução ao DDD

648
views

Published on

Introdução a DDD - Palestra .NetRaptors 100loop apresentada para unibh

Introdução a DDD - Palestra .NetRaptors 100loop apresentada para unibh

Published in: Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
648
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
28
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. .com Introdução ao D D D@CharlesFortes
  • 2. Introdução aoDomain-Driven Design .com O que é Domain-DrivenDesign ? @CharlesFortes
  • 3. Introdução aoDomain-Driven Design .com É Desenvolver Focado no Domínio @CharlesFortes
  • 4. Introdução aoDomain-Driven Design .com WTF? É Desenvolver Focado no Domínio @CharlesFortes
  • 5. Introdução aoDomain-Driven Design .com Domínio Segundo o Dicionário: • Esfera de Ação; Competência; Conhecimento. • O conteúdo de uma área de conhecimento. @CharlesFortes
  • 6. Introdução aoDomain-Driven Design .com Domínio é a área de conhecimento do negócio. Tudo do Software ligado ao negócio faz parte do domínio @CharlesFortes
  • 7. Introdução aoDomain-Driven Design .comLocadora Locação Dependentes de Filme Locadora Mídias Locadora Filmes Cliente Locadora Cadastros de Reserva Meu Negócio: Clientes e de Filme Locar Filmes Dependentes Locadora Funcionários Fornecedor ... Locadora Usuários @CharlesFortes
  • 8. Introdução aoDomain-Driven Design .com NÃO faz parte do domínio Banco de Dados ou Frameworks para os mesmos como o Nhibernate Threads Tratamentos de Excessão @CharlesFortes
  • 9. Introdução aoDomain-Driven Design .com Principais Vantagens Camadas bem definidas Responsabilidades claras e bem divididas Manutenabilidade, Longevidade, Escalabilidade, etc... As tecnologias mudam muito mais rápido do que o negócio @CharlesFortes
  • 10. Introdução aoDomain-Driven Design .com Principais Desvantagens Complexidade! Não é a solução para todos os problemas... Mais tempo para desenvolver (porém poupa tempo futuro durante a manutenção e a extensão) @CharlesFortes
  • 11. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua Para o entendimento do domínio deve-se gerar um MODELO do domínio @CharlesFortes
  • 12. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua WTF? ? MODELO @CharlesFortes
  • 13. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua Os modelos são abstrações que visam refletir o código Evans cita em seu livro que o modelo não pode ser "gordo" demais ao ponto de prejudicar a compreensão do domínio. @CharlesFortes
  • 14. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua E o código, por sua vez, deve ser usado para detalhar o modelo. Regras importantes devem estar expostas no modelo, e jamais escondidas no código. @CharlesFortes
  • 15. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua O modelo deve ser muito claro! Deve ser entendido absolutamente da mesma forma por qualquer pessoa, seja ele o usuário, o desenvolvedor, o arquiteto, o projetista, o designer a menina do marketing, a tia do café, e até o tester ( sim, ele também tem que ser capaz de entender só de ler ) @CharlesFortes
  • 16. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua Para que o modelo seja entendido é necessário uma linguagem ubíqua! @CharlesFortes
  • 17. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua WTF? Para que o modelo seja entendido é necessário uma linguagem ubíqua! @CharlesFortes
  • 18. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua Uma linguagem ubíqua é uma linguagem única falada por todos os envolvidos no projeto, de forma que a todo momento possa-se conversar sobre o projeto sem ter de ficar traduzindo o que está sendo falado @CharlesFortes
  • 19. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem UbíquaTudo isso para evitar mausentendidos @CharlesFortes
  • 20. Introdução aoDomain-Driven Design .com O Modelo e a Linguagem Ubíqua O modelo pode ser qualquer coisa, contanto que consiga expressar de forma clara o domínio @CharlesFortes
  • 21. Introdução aoDomain-Driven Design .comTodo o domínio(implementação) giram em tornodo modelo @CharlesFortes
  • 22. Introdução aoDomain-Driven Design .com0100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100010000011110101010111111000001110011011010100101010100000111001101101010010101010010000011110100000001110001000001111010101011111100000111001101101010010101010000011100110110101001010101001000001111010000000111000100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100 Lets Model01000001111010101011111100000111001101101010010101010000011100110110101001010101001000001111010000000111000100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100010000011110101010111111000001110011011010100101010100000111001101101010010101010010000011110100000001110001000001111010101011111100000111001101101010010101010000011100110110101001010101001000001111010000000111000100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100 @CharlesFortes
  • 23. Introdução ao Domain-Driven Design .comos Serviços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entidades Objet @CharlesFortes
  • 24. Introdução aoDomain-Driven Design .com Entidades são objetos que têm significado no domínio, possuindo uma identidade única Cliente Filme Usuário Entidades Funcionário Dependente Mídia @CharlesFortes
  • 25. Introdução ao Domain-Driven Design .comos Serviços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entidades @CharlesFortes
  • 26. Introdução aoDomain-Driven Design .com Objetos de Valor não tem valor direto ao negócio, e por isto não possuem uma identidade. Bairro Numero etc Usados como estrutura de Logradouro Endereco dados apenas para armazenar valores. Cliente etc Muito usados para transporte de dados ou composição de Nome Telefone objetos. CPF @CharlesFortes
  • 27. Introdução ao Domain-Driven Design .comos Serviços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entidades Objet @CharlesFortes
  • 28. Introdução aoDomain-Driven Design .com Repositórios são responsáveis por persistir, recuperar e destruir objetos Fingem possuir todas as entidades na memória, para quem utiliza não importa onde estão os dados @CharlesFortes
  • 29. Introdução aoDomain-Driven Design .comFingem possuir todas as entidades na memória, paraquem utiliza não importa onde estão os Armários de Caixasdados (Sim, foi feito no paint...) @CharlesFortes
  • 30. Introdução ao Domain-Driven Design .comos Serviços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entidades Objet @CharlesFortes
  • 31. Introdução aoDomain-Driven Design .com Serviços na visão do DDD consiste em um objeto que visa resolver problemas do domínio Para isto o “service” utiliza Entidades, Objetos de Valor, Repositórios, infraestrutura, etc.. @CharlesFortes
  • 32. Introdução aoDomain-Driven Design .comServiços na visão do DDD consiste em um objeto que visa resolverproblemas do domínio Locar Filme Cadastrar Cliente Meu Negócio: Etc... Locar Filmes Pesquisar Reservar Filme Filme @CharlesFortes
  • 33. Introdução ao Domain-Driven Design .comos Serviços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entid @CharlesFortes
  • 34. Introdução aoDomain-Driven Design .com Muitas vezes criar um novo objeto para atender a um aspecto do domínio envolve a instanciação de diversas entidades, agregações e composições. Outras vezes pode ser necessário decidir entre valores de inicialização padrão ou mesmo da especialização da classe. Quando isto se faz necessário não o fazemos dentro do construtor da classe, passamos esta responsabilidade para uma fábrica. @CharlesFortes
  • 35. Introdução aoDomain-Driven Design .com @CharlesFortes
  • 36. Introdução aoDomain-Driven Design .com Neste caso a especialização na construção é prática pois: • As entidades são mapeadas em diferentes tabelas do banco de dados • As entidades possuem diferentes validadores @CharlesFortes
  • 37. Introdução aoDomain-Driven Design .com0100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100010000011110101010111111000001110011011010100101010100000111001101101010010101010010000011110100000001110001000001111010101011111100000111001101101010010101010000011100110110101001010101001000001111010000000111000100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100 Lets Code01000001111010101011111100000111001101101010010101010000011100110110101001010101001000001111010000000111000100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100010000011110101010111111000001110011011010100101010100000111001101101010010101010010000011110100000001110001000001111010101011111100000111001101101010010101010000011100110110101001010101001000001111010000000111000100000111101010101111110000011100110110101001010101000001110011011010100101010100100000111101000000011100 @CharlesFortes
  • 38. Introdução aoDomain-Driven Design .com Concluindo... Defina uma linguagem única, expresse o negócio do cliente de forma clara e certifique-se que TODOS falam a mesma língua. Implemente de forma que o código traduza de forma analítica o que está foi modelado, para que daqui a 20 anos, quando o estagiário for mexer no fonte, ele saiba do que se trata, e se não souber, pode consultar ao productOwner sem problemas. E lembre-se do princípio de fazer simples, refatorar e melhorar sempre. @CharlesFortes
  • 39. Introdução aoDomain-Driven Design @CharlesFortes br.linkedin.com/in/charlesfortes pangeanet.org/profile/charlesfortes