Domínios, do monolítico ao micro-serviço

Transcript

1. Domínios do monolítico ao micro-serviço
2. Vinicius Reis @vinicius73 @LuizVinicius73 Gravo aulas sobre Vue.js, JavaScript e Laravel para codecasts.com.br Engenheiro de Aplicações @ Decision6
3. DDD Domain-Driven Design? Domain-Driven Development?
4. Não importa. O foco é entender como domínios funcionam e como ajudam no desenvolvimento de softwares
5. Domínios ❏ Contextos ❏ Assuntos ❏ Grupo de interesse ❏ Business Layer ❏ Object-Value ❏ Módulos ❏ Modelos ❏ Entidades ❏ Tabelas ❏ Não se resumem a serviços
6. Domínios São excelentes para manter a organização, separação e reaproveitamento das regras de negócio Tem a capacidade de traduzir o funcionamento do produto em organização. Não tem acesso a input/output Raramente domínios vão possuir views dentro deles. Evite a palavra Módulo, domínios não são módulos. Módulo possui muitos significados em diversos contextos, de linguagem, plataforma, frameworks, arquitetura, comercial...
7. Domain Based
8. Domain Based + PHP PSR-4 + Composer = Qualidade de Vida Namespaces garantem uma boa organização dos domínios. Composer permite criar pacotes para cada domínio, assim como seus relacionamentos/dependências.
9. Domain Based + Laravel Laravel + DDD = PSR-4 + Composer = Qualidade de Vida Projetos Laravel se adaptam muito bem a uma arquitetura baseada em domínios, é possível ir do mais simples, tendo apenas uma pasta a mais que contenha os domínios, até algo mais com complexo, modificando completamente estrutura de pastas iniciais. Ao iniciar um projeto Laravel você está apenas iniciando em seu boilerplate, Tudo ali pode ser modificado, não há amarras ou limitações.
10. Domain Based + Codecasts Support Domain Units Support não deve depender do domínio ou das Unidades Domínio pode depender de Suporte, mas não das unidades Unidades podem depender de ambos suporte e Domínio http://bit.ly/2yCI70n
11. Interessante... Porém onde monolíticos e micro-serviços entram nessa conversa?
12. Monolíticos
13. Monolíticos Você sabe quem eles são, são quase todos os projetos que você já criou
14. Monolíticos ❏ Uma aplicação ❏ Uma base de código ❏ Simples de iniciar ❏ São baratos de se produzir ❏ Quase sempre única instância de servidor ❏ Difícil manter atualizado ❏ Castelo de cartas ❏ Com o tempo se tornam legados... ❏ Custa caro escalar ❏ Difíceis de manter por longos períodos
15. Monolíticos Em geral estão atrelados ao MVC, a equipe se sente à vontade com o projeto. O custo inicial é baixo além de rapidamente mostrar resultados. Simples de colocar em produção e monitorar. Testes (quando existem) são caros. Com o tempo correções geram mais bugs, um ciclo vicioso de problemas. Manter atualizado pode ser impossível, pois os impactos podem ser imprevisíveis. Escalar é caro, não é simples separar processos em várias instâncias menores.
16. Micro Serviços
17. Micro Serviços Alguém realmente sabe definir Micro Serviços?
18. Monolítico Micro Serviços http://bit.ly/2yCI70n
19. Micro Serviços ❏ Facilmente escalável ❏ Fácil de manter atualizado ❏ Não fica preso a uma stack ❏ Permite centralização e reuso de operações ❏ Permite um melhor gerenciamento de recursos e custos ❏ Curva de adaptação e implementação elevada ❏ Exige bastante alinhamento da equipe ❏ Dependendo da stack e arquitetura possui latência considerável
20. Micro Serviços Permite ter uma grande resiliência da aplicação, se um serviço cair ou ficar lento, não vai impactar toda a aplicação. Permite gerenciar com precisão os serviços mais vitais ou que consomem mais recursos. É um grande desafio, não há um “guia de boas práticas”. As referências do mercado geralmente são grandes de mais para serem seguidas ou possuem muitas particularidades. Inicialmente possui um custo muito elevado, que só se paga no médio-longo prazo.
21. Micro Serviços Micro Serviços são como domínios, não representam entidades. Porém, não são tão abrangentes, um Micro Serviço precisa ter um objetivo extremamente específico, quase único. S.O.L.I.D. no nível do software.
22. Micro Serviços como Micro APIs Estamos falando de PHP, estamos falando de WEB, falando de HTTP. Tratar Micro Serviços como Micro APIs não está completamente correto, porém torna o assunto mais tangível.
23. Micro APIs São objetivas, expressão ações ou manipulações muito específicas. Exemplos: ❏ Envio de e-mails ❏ Geradores de relatórios ❏ Autenticação ❏ Grandes massas de processamento ❏ Gateways
24. Micro APIs Não caia na tentação de criar serviços com a responsabilidade única de manipular uma determinada entidade do banco de dados.
25. Micro APIs Nem toda APIs precisa ser acessível externamente, serviços que consomem outros serviços são comuns. Muitas vezes usa-se API-Gateways para facilitar o acesso aos serviços, além deles, ferramentas como GraphQL também ajudam a lidar com múltiplos serviços.
26. E agora?
27. E agora? A teoria é muito bonita. Micro Serviços não é o Santo Graal. Monolíticos não são vilões.
28. Micro APIs + Monolíticos
29. Micro APIs + Monolíticos Migrar aos poucos, e em partes, de Monolítico para Micro Serviços, é uma abordagem comum. Mover operações mais críticas ou mais pesadas para um Serviço ou API especializados trará, logo no início, um grande poder de escala.
30. Micro APIs + Monolíticos ~> Domain Based Mover uma operação não é simples, tal ação pode fragmentar as regras de negócio da aplicação. Para solucionar isso é possível usar o domínio como pacote, compartilhando ele entre o serviço e o monolítico.
31. Monolítico como Serviço (!?) Mais opções...
32. Monolítico como Serviço Muitas vezes as regras de negócio estão estão complexas e amarradas que extrair essas regras beira o impossível. Para essas situações, encapsular o monolítico através de Micro Serviços é uma opção válida.
33. Monolítico como Serviço Monolito Serviço A Serviço B Serviço C Serviço D
34. Instância como Serviço Mais opções...
35. Instância como Serviço Subir mais de uma instância da aplicação e controlar o acesso a elas baseado em segmentos da URL pode ser uma abordagem válida para escalar.
36. Instância como Serviço Monolito A1 Monolito A2 POST /report/weekly GET /products GET /clients POST /payments/spend Proxy ou Gateway
37. tl;dr
38. Domínios são úteis Centralize suas regras de negócio, porém, não permita que eles fiquem presas a contextos de input/output. Seu controller é quem vai passar esses inputs e devolver os outputs, Ele é o responsável por isso, receber pedidos e devolver html, json, imagens...
39. Monolíticos não são vilões Você não vai parar de desenvolver suas aplicações de forma monolítica, ainda há valor nessa abordagem. Porém, com a evolução do seu produto, a necessidade de escala vai aparecer, nesse momento estará na noha de começar a usar Micro Serviços. Se a aplicação foi criada usando Domain Based, o custo dessa evolução será baixo.
40. Micro Serviços ou Micro APIs Já sabemos as vantagens de Micro Serviços, porém não sabemos de fato como criar eles, e principalmente como criar eles de forma barata. Não somos a Netflix. A abordagem mais simples e trabalhar com Micro APIs, usando pacotes como domínios, compartilhando as regras de negócios comuns entre os serviços. Lembre-se, nem toda API é acessível externamente.
41. Ainda há opções além dos Micro Serviços Nem sempre há a possibilidade ou tempo para se usar Micro Serviços. Técnicas de escala ainda são úteis, além de truques como ter uma instância responsável por um grupo de requests. Mesmo sendo possível, evite essas abordagens.
42. Pense sempre em pacotes “desenvolvimento orientado a pacotes” Desenvolver pensando em pacotes vantajoso por vários motivos. Vai facilitar manutenção, reuso e evolução do projeto. A camada Domains e Support são excelentes candidatos para essa abordagem.
43. Obrigado!
44. http://bit.ly/ddd-monolitico-micro-services