Baixado 51 vezes
Carregado porCharles Fortes
Introdução ao DDD
O documento introduz os principais conceitos do Domain-Driven Design (DDD), incluindo: 1) O foco do DDD é no domínio do negócio e suas regras de negócio; 2) É necessário criar um modelo claro do domínio usando uma linguagem ubíqua; 3) Entidades, objetos de valor, repositórios e serviços são elementos importantes do modelo.
Introdução ao DDD
- 1. D D D Introduçãoao @CharlesFortes .com
- 2. Domain-Driven Design Introdução ao @CharlesFortes .com Oque é Domain-DrivenDesign?
- 3. Domain-Driven Design Introdução ao @CharlesFortes .com ÉDesenvolver Focado no Domínio
- 4. Domain-Driven Design Introdução ao @CharlesFortes .com ÉDesenvolver Focado no Domínio WTF?
- 5. Domain-Driven Design Introdução ao @CharlesFortes .com DomínioSegundo o Dicionário: • Esfera de Ação; Competência; Conhecimento. • O conteúdo de uma área de conhecimento.
- 6. Domain-Driven Design Introdução ao @CharlesFortes .com Domínioé a área de conhecimento do negócio. Tudo do Software ligado ao negócio faz parte do domínio
- 7. Locadora Locadora Locadora Locadora Locadora Locadora Domain-Driven Design Introdução ao @CharlesFortes .com MeuNegócio: Locar Filmes Fornecedor Mídias Filmes Usuários Funcionários Dependentes Cliente Locação de Filme Reserva de Filme ... Cadastros de Clientes e Dependentes
- 8. Domain-Driven Design Introdução ao @CharlesFortes .com NÃOfazparte do domínio Banco de Dadosou Frameworks para os mesmos como o Nhibernate Threads Tratamentos de Excessão
- 9. Domain-Driven Design Introdução ao @CharlesFortes .com PrincipaisVantagens As tecnologias mudam muito mais rápido do que o negócio Camadas bem definidas Responsabilidades claras e bem divididas Manutenabilidade, Longevidade, Escalabilidade, etc...
- 10. Domain-Driven Design Introdução ao @CharlesFortes .com PrincipaisDesvantagens Mais tempo para desenvolver (porém poupa tempo futuro durante a manutenção e a extensão) Complexidade! Não é a solução para todos os problemas...
- 11. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo e a Linguagem Ubíqua Para o entendimento do domínio deve-se gerar um MODELO do domínio
- 12. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo e a Linguagem Ubíqua MODELO WTF? ?
- 13. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo 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.
- 14. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo 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.
- 15. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo 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é, etc
- 16. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo e a Linguagem Ubíqua Para que o modelo seja entendido é necessário uma linguagem ubíqua!
- 17. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo e a Linguagem Ubíqua Para que o modelo seja entendido é necessário uma linguagem ubíqua! WTF?
- 18. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo 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
- 19. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo e a Linguagem Ubíqua Tudo isso para evitar maus entendidos
- 20. Domain-Driven Design Introdução ao @CharlesFortes .com OModelo e a Linguagem Ubíqua O modelo pode ser qualquer coisa, contanto que consiga expressar de forma clara o domínio
- 21. Domain-Driven Design Introdução ao @CharlesFortes .com Todoo domínio (implementação) giram em torno do modelo
- 22. Domain-Driven Design Introdução ao @CharlesFortes .com LetsModel 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
- 23. Domain-Driven Design Introdução ao @CharlesFortes .com osServiços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entidades Objet
- 24. Domain-Driven Design Introdução ao @CharlesFortes .com Entidadessão objetos que têm significado no domínio, possuindo uma identidade única Entidades UsuárioFilme Funcionário Mídia Dependente Cliente
- 25. Domain-Driven Design Introdução ao @CharlesFortes .com osServiços Fabricas Entidades Objetos de Valor Repositórios Serviços Fabricas Entidades
- 26. Domain-Driven Design Introdução ao @CharlesFortes .com Objetosde Valor não tem valor direto ao negócio, e por isto não possuem uma identidade. Cliente Nome CPF Telefone Endereco Usados como estrutura de dados apenas para armazenar valores. Muito usados para transporte de dados ou composição de objetos. Logradouro Numero Bairro etc etc
- 27. Domain-Driven Design Introdução ao @CharlesFortes .com osServiços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entidades Objet
- 28. Domain-Driven Design Introdução ao @CharlesFortes .com Repositóriossãoresponsá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
- 29. Domain-Driven Design Introdução ao @CharlesFortes .com Armáriosde Caixas Fingem possuir todas as entidades na memória, para quem utiliza não importa onde estão os dados (Sim, foi feito no paint...)
- 30. Domain-Driven Design Introdução ao @CharlesFortes .com osServiços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entidades Objet
- 31. Domain-Driven Design Introdução ao @CharlesFortes .com Serviçosna 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..
- 32. Domain-Driven Design Introdução ao @CharlesFortes .com MeuNegócio: Locar Filmes Locar Filme Reservar Filme Cadastrar Cliente Pesquisar Filme Etc... Serviços na visão do DDD consiste em um objeto que visa resolver problemas do domínio
- 33. Domain-Driven Design Introdução ao @CharlesFortes .com osServiços Fabricas Entidades Objetos de Valor Repositórios ServiçosFabricas Entid
- 34. Domain-Driven Design Introdução ao @CharlesFortes .com Muitasvezes criar um novo objeto para atender a um aspecto do domínio envolve a instanciação de diversas entidades, agregações e composições. Quando isto se faz necessário não o fazemos dentro do construtor da classe, passamos esta responsabilidade para uma fábrica. Outras vezes pode ser necessário decidir entre valores de inicialização padrão ou mesmo da especialização da classe.
- 35.
- 36. Domain-Driven Design Introdução ao @CharlesFortes .com Nestecaso 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
- 37. Domain-Driven Design Introdução ao @CharlesFortes .com LetsCode 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 0 0 1 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0
- 38. Domain-Driven Design Introdução ao @CharlesFortes .com Concluindo... Definauma 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.
- 39.