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

Transcript

1. Limites E contextos Como DDD ajuda Na modelagem de Microserviços blog.eriksen.com.br/palestras
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 “ ”
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 “ ”
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
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)
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