Este documento apresenta conceitos de arquitetura de software para aplicações Node.js, incluindo padrões como camadas de domínio, repositório e controlador separados, testes automatizados e implantações seguras. O objetivo é construir aplicações escaláveis e de fácil manutenção aplicando boas práticas de engenharia de software.

1. Indo além do MVC
com Node.JS
by Gustavo S. Rodrigues (@gustavo_s_r)

2. Sobre o palestrante
Sou um arquiteto de soluções
apaixonado por linhas de códigos e
por problemas não convencionais.
Já atuei como executivo de contas,
analista de QA, analista de
requisitos, programador Front-end,
Programador Back-end,
Desenvolvedor Full-Stack e
Arquiteto de Soluções prestando
serviços para clientes como Porto
Seguro, Terra, Claro e Natura. Gustavo S. Rodrigues

3. Sobre o que falaremos?

4. Essa palestra tem o objetivo de
apresentar conceitos de construção
de aplicações escaláveis e de fácil
manutenção, aplicando padrões de
projetos conhecidos mas com
Node.js

5. Keep it simple
stupid

6. Um bom software não é aquele que
tem menos linhas de código, assim
como não é o que implementa
funções ou atribuições complexas.

7. Qual dessas estruturas encontramos mais
complexidade?
/models
/routes
/modules(ou libs)
index.js
config.js
middlewares.js
package.json
/configs/
/infraestructure/providers/{external_resources}
/infraestructure/adapters/
/domains/models/
/domains/repositories/
/domains/datasource.js
/http/controllers/
/http/middlewares/
/http/routes/
/modules/
index.js
package.json
?!

8. /configs/
/infraestructure/providers/{external_
resources}
/infraestructure/adapters/
/domains/models/
/domains/repositories/
/domains/datasource.js
/http/controllers/
/http/middlewares/
/http/routes/
/modules/
index.js
package.json

9. Don't repeat
yourself

10. Estruturas mal definidas ou muito
reduzidas tendem a trazer consigo mais
responsabilidades para um bloco de
código, e por sua vez gera uma curva
exponencial de complexidade, que
dificulta a sustentação desse projeto

11. Show me the code!

12. O Que são Repositories?

13. Repository
Um sistema com um modelo de domínio complexo geralmente se beneficia de uma camada, como a
fornecida pelo Data Mapper (165), que isola os objetos de domínio dos detalhes do código de acesso ao
banco de dados. Em tais sistemas, pode valer a pena construir outra camada de abstração sobre a
camada de mapeamento, onde o código de construção da consulta é concentrado. Isso se torna mais
importante quando há um grande número de classes de domínio ou consultas pesadas. Nesses casos,
especialmente, adicionar essa camada ajuda a minimizar a lógica de consulta duplicada. Um Repositório
medeia entre o domínio e as camadas de mapeamento de dados, agindo como uma coleção de objetos
de domínio na memória. Objetos clientes constroem especificações de consulta declarativamente e as
submetem ao Repositório para satisfação. Objetos podem ser adicionados e removidos do Repositório,
como eles podem de uma simples coleção de objetos, e o código de mapeamento encapsulado pelo
Repositório realizará as operações apropriadas nos bastidores. Conceitualmente, um Repositório
encapsula o conjunto de objetos persistidos em um armazenamento de dados e as operações
executadas sobre eles, fornecendo uma visão mais orientada a objeto da camada de persistência. O
Repository também suporta o objetivo de obter uma separação limpa e uma dependência unidirecional
entre o domínio e as camadas de mapeamento de dados. (Patterns of Enterprise Application Architecture,
Martin Fowler)

14. Separar a regra de abstração de dados das regras de
controle te traz a flexibilidade de em apenas um lugar
controlar os provedores de dados, tornando mais fácil
a implementação de uso de mais de uma modalidade
de banco de dados ou de implementação de cache de
dados, sem se preocupar com re-implementar isso em
todos os controllers.

15. Por que separar
camada de controller
das camadas de rota?

16. Temos a tendência natural de acreditar que controller
deve por si só resolver chamadas http, mas a partir
dos momento que sua aplicação pode ser invocada via
função Lambda por handler, ou que sua controller
pode ser invocada por uma instrução bash, você
começa a observar que o controller serve para tratar
regras de negócio, recebendo dados de entrada,
tratando-os e devolvendo algo, e é papel de quem o
implementa definir o protocolo de entrada e saída,
seja HTTP ou não.

17. Existem outros modelos?

18. Claro que sim, depende do tamanho e da
complexidade do sistema que você pretende
construir, o modelo anterior colocamos apenas
algumas camadas de apoio para suportar mudanças
de forma mais simples, mas existem modelos mais
granulares como o do próximo slide.

19. Modelos
ONION
https://medium.com/@domagojk/patterns-for-designing-flexible-
architecture-in-node-js-cqrs-es-onion-7eb10bbefe17

20. Modelos
ONION
https://medium.com/@Killavus/hexagonal-architecture-in-
javascript-applications-and-how-it-relates-to-flux-349616d1268d

21. Fazer simples é mais difícil do que sair implementado
código, mas o preço que se paga é gigantesco quando
seu projeto cresce!

22. E o que vem depois?

23. Não é possível implementar bons padrões de
arquitetura sem uma inteira remodelagem no seu
processo de delivery!

24. TDD ou BDD
Independente do conceito aplicado,
teste, faça sempre uma cobertura
de teste no mínimo de 80% da sua
aplicação, entre testes unitários e
end-to-end.

25. Automatize atualizações
Com uma boa cobertura de testes,
algumas coisas como atualização
de pacotes de forma automática
para garantir o uso dos módulos em
suas versões mais atualizadas e
seguras utilizando o Renovate Bot
(https://renovatebot.com/)

26. Garanta deploys seguros
Além de utilizar uma boa ferramenta
de CI/CI, é importante que além de
automatizar o processo de build,
que se automatize os testes, e mais
do que isso, que garanta que seu
projeto continue seguro.

27. Faça uma arquitetura de
referência
Mais importante que usar boas
práticas de desenvolvimento,
documente, crie boilerplates básicos
de implementações para reuso,
construa libs e mais do que isso,
compartilhe código com a
comunidade.

28. Onde Aprender mais sobre Good parts?

29. Links
12 Fator - https://12factor.net/pt_br/
System design primer - https://github.com/donnemartin/system-design-primer/
P of EAA - https://martinfowler.com/books/eaa.html
SOLID NODE - https://medium.com/@domagojk/patterns-for-designing-flexible-
architecture-in-node-js-cqrs-es-onion-7eb10bbefe17

30. Dúvidas?

31. Obrigado!
Medium: https://medium.com/@gustavosrodrigues
Twitter: @gustavo_s_r
Linkedin: https://www.linkedin.com/in/gustavosilvarodrigues/