Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

DDD Domain-Driven Design? Domain-Driven Development?

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Domain Based

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Monolíticos

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

Micro Serviços

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

E agora?

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Micro APIs + Monolíticos

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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.

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

tl;dr

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

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.

Slide 43

Slide 43 text

Obrigado!

Slide 44

Slide 44 text

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