Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

503e17102f7c813397aa672a32756b54?s=128

eriksencosta

May 17, 2017
Tweet

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

  13. None
  14. None
  15. None
  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)

  20. None
  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

  28. None
  29. None
  30. None
  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)
  36. None
  37. None
  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?

  45. None
  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

  51. None
  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