Limites e contextos: como DDD ajuda na modelagem de Microserviços

Limites e contextos: como DDD ajuda na modelagem de Microserviços

Microserviços são o primeiro estilo arquitetural pós-DevOps, que tem, entre seus benefícios, estrutura modular evidente, deploy independente e diversidade tecnológica.

Domain-Driven Design (DDD) é um framework de design de software que possui ferramentas muito úteis para a modelagem de serviços. Microserviços, por sua vez, força uma separação clara entre os componentes de um sistema (neste caso, dos serviços) que é benéfica para a aplicação do DDD.

Essa interação, para uns um princípio de Microserviços, é um círculo virtuoso entre o estilo arquitetural e a aplicação de DDD.

Referências e mais informações em: https://blog.eriksen.com.br/palestras/microservicos-ddd

503e17102f7c813397aa672a32756b54?s=128

eriksencosta

July 21, 2017
Tweet

Transcript

  1. Limites E contextos Como DDD ajuda Na modelagem de Microserviços

    blog.eriksen.com.br/palestras
  2. None
  3. Com certeza só atrapalha. Há muita Complexidade nos serviços, e

    o sistema Como um todo é muito instável. Iniciativas Novas estão paradas por causa disso – 14 serviços @ 7 desenvolvedores “ ”
  4. Usamos microserviços, mas não está dando Certo. Tem um serviço

    que apenas move um Arquivo De um lugar pro outro no sistema de arquivos: Tem umas 20 classes! – 12 serviços @ 34 desenvolvedores “ ”
  5. None
  6. Microserviços são o primeiro estilo arquitetural pós-revolução DevOps, é O

    primeiro a abraçar completamente as Práticas dE engenharia da entrega contínua – Neal Ford e Rebecca Parsons “ ”
  7. Microserviços

  8. Microserviços são serviços pequenos E autônomos que trabalham em conjunto

    – Sam Newman “ ”
  9. É uma forma de desenvolver uma aplicação como uma Suíte

    de pequenos serviços, cada qual rodando em seu Próprio processo (...). Esses serviços são construídos Ao Redor de capacidades de negócio e são implantados Independentemente com processos automatizados. (...) Podem ser escritos em diferentes linguagens e usar Tecnologias diferentes de armazenamento de dados – James Lewis e Martin Fowler “ ”
  10. Estrutura modular evidente

  11. Estrutura modular evidente Deploy independente

  12. Estrutura modular evidente Diversidade tecnológica Deploy independente

  13. Estrutura modular evidente Ciclo mais rápido de entrega Diversidade tecnológica

    Deploy independente
  14. Estrutura modular evidente Ciclo mais rápido de entrega Diversidade tecnológica

    Deploy independente Maior resiliência
  15. Estrutura modular evidente Ciclo mais rápido de entrega Diversidade tecnológica

    Reuso de funcionalidade Deploy independente Maior resiliência
  16. Uma arquitetura evolutiva possibilita Mudança Em uma arquitetura como um

    Primeiro Princípio. É atraente porque Mudança tem sido historicamente cara e difícil De Antecipar – Neal Ford e Rebecca Parsons “ ”
  17. É uma arquitetura evolutiva por causa Do seu forte princípio

    de Contexto Delimitado, Tornando a divisão lógica do Domain-Driven Design uma separação física – Neal Ford e Rebecca Parsons “ ”
  18. Questionamentos se design é necessário ou Acessível perdem o ponto:

    design é inevitável. A alternativo para bom design é design ruim, E não a ausência de design – Douglas Martin “ ”
  19. Domain-Driven Design

  20. O DDD é uma forma de desenvolver software que tem,

    como objetivo, implementar o melhor design de software baseado em modelos que refletem as competências da organização – Vaughn Vernon “ ”
  21. None
  22. None
  23. None
  24. 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 “ ”
  25. DDD é primariamente sobre modelar Uma linguagem ubíqua em um

    Contexto delimitado – Vaughn Vernon “ ”
  26. Contexto Delimitado (Bounded Context)

  27. Contexto Delimitado (Bounded Context) Linguagem Ubíqua (Ubiquitous Language)

  28. Linguagem Ubíqua (Ubiquitous Language) modelamos isso dentro Veículo Contexto Delimitado

    (Bounded Context) Itinerário Motorista
  29. Itinerário Veículo Perna Comprovante Motorista Destinatário Entrega Contexto Transporte (Core

    Domain)
  30. = + + Contexto Time Banco de dados Repositório

  31. Rota Veículo Carga Nó Contexto Roteirização (Genérico)

  32. Contexto Agendamento (Suporte) Conta Entrega Nota Fiscal Comprovante

  33. Contexto Identificação (Genérico) Conta Usuário Permissão

  34. Contexto Monitoramento (Suporte) Veículo Remessa Motorista

  35. None
  36. Parceria

  37. Cliente-fornecedor Downstream (cliente) Upstream (fornecedor)

  38. Camada Anti-corrupção (Anticorruption Layer)

  39. Conformista

  40. D u D u Contexto Transporte (Core Domain) Roteirização (Genérico)

    Agendamento (Suporte) Identificação (Genérico) Monitoramento (Suporte)
  41. None
  42. Microserviços criam uma barreira concreta ao redor da lógica que

    um time está criando em um serviço particular. Limites lógicos não sobrevivem no mundo real, é muito fácil em um monólito, na pressa usar alguma coisa que se precisa – Eric Evans “ ”
  43. blog.eriksen.com.br/palestras eriksencosta@gmail.com @eriksencosta