Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Vinicius Reis

November 18, 2017
Tweet

More Decks by Vinicius Reis

Other Decks in Programming

Transcript

  1. Vinicius Reis @vinicius73 @LuizVinicius73 Gravo aulas sobre Vue.js, JavaScript e

    Laravel para codecasts.com.br Engenheiro de Aplicações @ Decision6
  2. Não importa. O foco é entender como domínios funcionam e

    como ajudam no desenvolvimento de softwares
  3. Domínios ❏ Contextos ❏ Assuntos ❏ Grupo de interesse ❏

    Business Layer ❏ Object-Value ❏ Módulos ❏ Modelos ❏ Entidades ❏ Tabelas ❏ Não se resumem a serviços
  4. 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...
  5. 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.
  6. 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.
  7. 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
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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.
  16. 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.
  17. E agora? A teoria é muito bonita. Micro Serviços não

    é o Santo Graal. Monolíticos não são vilões.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. Instância como Serviço Monolito A1 Monolito A2 POST /report/weekly GET

    /products GET /clients POST /payments/spend Proxy ou Gateway
  23. 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...
  24. 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.
  25. 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.
  26. 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.
  27. 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.