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. 2.
  2. 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 “ ”
  3. 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 “ ”
  4. 5.
  5. 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 “ ”
  6. 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 “ ”
  7. 15.

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

    Reuso de funcionalidade Deploy independente Maior resiliência
  8. 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 “ ”
  9. 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 “ ”
  10. 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 “ ”
  11. 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 “ ”
  12. 21.
  13. 22.
  14. 23.
  15. 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 “ ”
  16. 25.

    DDD é primariamente sobre modelar Uma linguagem ubíqua em um

    Contexto delimitado – Vaughn Vernon “ ”
  17. 35.
  18. 36.
  19. 40.

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

    Agendamento (Suporte) Identificação (Genérico) Monitoramento (Suporte)
  20. 41.
  21. 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 “ ”