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

Transcript

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

   View Slide

2. Vinicius Reis
   @vinicius73
   @LuizVinicius73
   Gravo aulas sobre Vue.js, JavaScript e Laravel para codecasts.com.br
   Engenheiro de Aplicações @ Decision6
   

   View Slide

3. DDD
   Domain-Driven Design?
   Domain-Driven Development?
   

   View Slide

4. Não importa.
   O foco é entender como domínios funcionam e
   como ajudam no desenvolvimento de softwares
   

   View Slide

5. Domínios
   ❏ Contextos
   ❏ Assuntos
   ❏ Grupo de interesse
   ❏ Business Layer
   ❏ Object-Value
   ❏ Módulos
   ❏ Modelos
   ❏ Entidades
   ❏ Tabelas
   ❏ Não se resumem a serviços
   

   View Slide

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

   View Slide

7. Domain Based
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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
    

    View Slide

11. Interessante...
    Porém onde monolíticos e micro-serviços
    entram nessa conversa?
    

    View Slide

12. Monolíticos
    

    View Slide

13. Monolíticos
    Você sabe quem eles são, são quase todos os
    projetos que você já criou
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

16. Micro Serviços
    

    View Slide

17. Micro Serviços
    Alguém realmente sabe definir Micro Serviços?
    

    View Slide

18. Monolítico
    Micro Serviços
    http://bit.ly/2yCI70n
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

26. E agora?
    

    View Slide

27. E agora?
    A teoria é muito bonita.
    Micro Serviços não é o Santo Graal.
    Monolíticos não são vilões.
    

    View Slide

28. Micro APIs + Monolíticos
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

31. Monolítico como Serviço (!?)
    Mais opções...
    

    View Slide

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.
    

    View Slide

33. Monolítico como Serviço
    Monolito
    Serviço A
    Serviço B
    Serviço C
    Serviço D
    

    View Slide

34. Instância como Serviço
    Mais opções...
    

    View Slide

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.
    

    View Slide

36. Instância como Serviço
    Monolito A1
    Monolito A2
    POST /report/weekly
    GET /products
    GET /clients
    POST /payments/spend
    Proxy
    ou
    Gateway
    

    View Slide

37. tl;dr
    

    View Slide

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

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

43. Obrigado!
    

    View Slide

44. http://bit.ly/ddd-monolitico-micro-services
    

    View Slide