Domain-Driven Design: uma introdução para desenvolvedores, artistas, responsáveis ou degustadores de café com leite

Domain-Driven Design (DDD) é uma forma de desenvolver software que foca em implementar o melhor design de software baseado em modelos que refletem explicitamente as competências da organização. DDD força a organização a entender onde deve se distinguir, ao mesmo tempo em a guia na criação de um modelo de software correto. Isso leva a software valioso, usável e também elimina desperdícios.

Referências e mais informações em: https://blog.eriksen.com.br/palestras/domain-driven-design-introducao

Transcript

1. Domain-Driven Design uma introdução para desenvolvedores, artistas, responsáveis ou degustadores de café com leite blog.eriksen.com.br/palestras
2. “Software está comendo o mundo” – Marc Andreessen “Software está comendo o mundo” – Marc Andreessen
3. Muitos projetos Ágeis estão Produzindo código ruim – Sandro Mancuso Muitos projetos Ágeis estão Produzindo código ruim – Sandro Mancuso “ “ ” ”
4. Questionamentos se design é necessário ou Acessível Perdem o ponto: design é inevitável. A alternativa para Bom design é design ruim, e não a ausência de design. – Douglas Martin Questionamentos se design é necessário ou Acessível Perdem o ponto: design é inevitável. A alternativa para Bom design é design ruim, e não a ausência de design. – Douglas Martin “ “ ” ”
5. Uma Grande Bola de Lama é uma selva de código Mal estruturado, desleixado, espaguete e todo Remendado com fita adesiva – Brian Foote & Joseph Yoder Uma Grande Bola de Lama é uma selva de código Mal estruturado, desleixado, espaguete e todo Remendado com fita adesiva – Brian Foote & Joseph Yoder “ “ ” ”
6. Domain-Driven design
7. É um enigma. As pessoas que são especialistas no Domínio – os especialistas de domínio – raramente Estão qualificadas para escrever software. As pessoas que estão qualificadas para escrever Software – os programadores – nem sempre Entendem O domínio-problema. – James Shore É um enigma. As pessoas que são especialistas no Domínio – os especialistas de domínio – raramente Estão qualificadas para escrever software. As pessoas que estão qualificadas para escrever Software – os programadores – nem sempre Entendem O domínio-problema. – James Shore “ “ ” ”
8. se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela. Software útil pode ser desenvolvido dessa Maneira, Mas o projeto nunca chegará em um ponto onde novas Funcionalidades poderosas surgirão como desdobramento de funcionalidades existentes. – Eric Evans se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela. Software útil pode ser desenvolvido dessa Maneira, Mas o projeto nunca chegará em um ponto onde novas Funcionalidades poderosas surgirão como desdobramento de funcionalidades existentes. – Eric Evans “ “ ” ”
9. Domínio
10. Domínio Core Domain
11. Domínio Core Domain Modelo
12. Domínio Core Domain Modelo
16. Design Estratégico é como fazer o rascunho antes De Entrar nos detalhes da implementação. Destaca O que é estrategicamente importante para o seu Negócio, como dividir o trabalho por importância E como fazer integrações da melhor maneira. – Vaughn Vernon Design Estratégico é como fazer o rascunho antes De Entrar nos detalhes da implementação. Destaca O que é estrategicamente importante para o seu Negócio, como dividir o trabalho por importância E como fazer integrações da melhor maneira. – Vaughn Vernon “ “ ” ”
17. DDD é primariamente sobre modelar Uma Linguagem Ubíqua em Um Contexto Delimitado – Vaughn Vernon DDD é primariamente sobre modelar Uma Linguagem Ubíqua em Um Contexto Delimitado – Vaughn Vernon ” ” “ “
18. Contexto Delimitado (Bounded Context)
19. Contexto Delimitado (Bounded Context) Linguagem Ubíqua (Ubiquitous Language)
21. Linguagem Ubíqua (Ubiquitous Language) modelamos isso dentro média Contexto SP Contexto Delimitado (Bounded Context)
22. = + + Contexto Time Banco de dados Repositório
23. Itinerário Veículo Perna Comprovante Motorista Destinatário Entrega Contexto Transporte (Core Domain)
24. Rota Veículo Carga Nó Contexto Roteirização (Genérico)
25. Contexto Agendamento (Suporte) Conta Entrega Nota Fiscal Comprovante
26. Contexto Identificação (Genérico) Conta Usuário Permissão
27. Contexto Monitoramento (Suporte) Veículo Remessa Motorista
31. Parceria
32. Cliente-fornecedor Downstream (cliente) Upstream (fornecedor)
33. Camada Anti-corrupção (Anticorruption Layer)
34. Conformista
35. D u D u Contexto Transporte (Core Domain) Roteirização (Genérico) Agendamento (Suporte) Identificação (Genérico) Monitoramento (Suporte)
38. Software funcionando é a medida primária de progresso – Princípio 7 do Manifesto Ágil Software funcionando é a medida primária de progresso – Princípio 7 do Manifesto Ágil ” ” “ “
39. No DDD há esse princípio de que o Software deve refletir o modelo explicitamentE – Eric Evans No DDD há esse princípio de que o Software deve refletir o modelo explicitamentE – Eric Evans ” ” “ “
40. package br.com.ligeirinho.transporte package dominio.modelo @EntidadeRaiz class Itinerario( val id: ItinerarioId, private val veiculo: Veiculo, private val pernas: List[Perna] ) extends Entidade { // ... def transferirEntregasPendentes(outroItinerario: Itinerario): Unit = { } def alocarMotorista(motorista: Motorista): Unit = { } def realocarParaMotorista(motorista: Motorista): Unit = { } // ... }
41. microserviços são serviços pequenos E autônomos que trabalham em conjunto – Sam Newman microserviços são serviços pequenos E autônomos que trabalham em conjunto – Sam Newman ” ” “ “
42. Se os limites dos nossos serviços alinhaM-se Aos Contextos Delimitados do nosso domínio, Nós começamos bem para garantir que nossos Microserviços estão com baixo acoplamento E alta coesão – Sam Newman Se os limites dos nossos serviços alinhaM-se Aos Contextos Delimitados do nosso domínio, Nós começamos bem para garantir que nossos Microserviços estão com baixo acoplamento E alta coesão – Sam Newman ” ” “ “
43. = + + Contexto Time Banco de dados Repositório
44. Como começar?
46. A arte nunca está terminada, é apenas abandonada – Leonardo da Vinci A arte nunca está terminada, é apenas abandonada – Leonardo da Vinci ” ” “ “
47. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo – Princípio 3 do Manifesto Ágil Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo – Princípio 3 do Manifesto Ágil ” ” “ “
48. 2016 2013 2003
49. Event Storming Event Storming
50. User Story Mapping User Story Mapping
52. Não podemos fugir da Responsabilidade de sermos humanos Nigel Warburton sobre a filosofia de Jean-Paul Sartre Não podemos fugir da Responsabilidade de sermos humanos Nigel Warburton sobre a filosofia de Jean-Paul Sartre “ “ ” ”
53. blog.eriksen.com.br/palestras eriksencosta@gmail.com @eriksencosta