You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* ci(.github): create gh actions scope for ci
* chore: remove circleci
* fix(ci): fixed ci process with gh
* fix(ci): better README with badges updated
Inspirado em desenvolver essa arquitetura depois de acompanhar algumas palestras da Nubank, a ideia de separação de responsabilidades por camadas e modelos de testes me fez inspirar a criar um modelo em Node.js.
13
+
Inspirado em desenvolver essa arquitetura depois de acompanhar
14
+
algumas palestras da Nubank, a ideia
15
+
de separação de responsabilidades
16
+
por camadas e modelos de testes me fez inspirar a criar um modelo em Node.js.
13
17
14
18
## O que vem a ser? Aonde vive? Hoje no globo reporter
15
19
16
-
Antes de tudo vamos no [Wikipedia](https://en.wikipedia.org/wiki/Hexagonal_architecture_(software))
20
+
Antes de tudo vamos no [Wikipedia](<https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)>)
17
21
Depois vamos paginar [esse slide bacana da Nubank](https://pt.slideshare.net/Nubank/arquitetura-funcional-em-microservices).
18
22
19
23
## Já viu os dois? senta que lá vem história
@@ -22,24 +26,30 @@ Depois vamos paginar [esse slide bacana da Nubank](https://pt.slideshare.net/Nub
22
26
23
27
Vamos elencar algumas dores do desenvolvimento:
24
28
25
-
* Mockar serviços ou testar neles;
26
-
* Criar uma condição de teste com volume aceitável de cobertura, e possibilidade do seu teste evoluir
27
-
conforme vai a experiência de consumo do produto;
28
-
* Projetar Tolerância a falha;
29
-
* Saber onde deve entrar o BDD e onde entra o teste unitário; e
30
-
* (para galera que curte o lado funcional do Javascript) criar codigo 100% puro sem ter que vender o rim.
29
+
- Mockar serviços ou testar neles;
30
+
- Criar uma condição de teste com volume aceitável de cobertura,
31
+
e possibilidade do seu teste evoluir
32
+
conforme vai a experiência de consumo do produto;
33
+
- Projetar Tolerância a falha;
34
+
- Saber onde deve entrar o BDD e onde entra o teste unitário; e
35
+
- (para galera que curte o lado funcional do Javascript) criar
36
+
codigo 100% puro sem ter que vender o rim.
31
37
32
38
### Dado isso vamos começar pela camada do meio, aonde ficam os negócios
33
39
34
-
* É a camada mais pura;
35
-
* Não conversa com ninguém, somente é consumido;
36
-
* Onde as funções DEVEM ser mais puras possíveis;
37
-
* Não precisam de implementar injeção de dependência;
38
-
* Não são assíncronas pois recebe tudo que precisa na entrada e devolve o objeto necessário; e
39
-
* São fáceis de fazer teste unitário porque são puros e com entradas que se limita a Arrays e objetos.
40
-
41
-
Nela deve ficar toda questão de negócios que sua solução propõe, sabemos que nessa área é onde vai ocorrer
42
-
mais mudanças conforme for evoluindo sua aplicação, então ela tem que ser simpática e amigável a ponto de voce nem ligar
40
+
- É a camada mais pura;
41
+
- Não conversa com ninguém, somente é consumido;
42
+
- Onde as funções DEVEM ser mais puras possíveis;
43
+
- Não precisam de implementar injeção de dependência;
44
+
- Não são assíncronas pois recebe tudo que precisa na entrada
45
+
e devolve o objeto necessário; e
46
+
- São fáceis de fazer teste unitário porque são puros
47
+
e com entradas que se limita a Arrays e objetos.
48
+
49
+
Nela deve ficar toda questão de negócios que sua solução propõe,
50
+
sabemos que nessa área é onde vai ocorrer
51
+
mais mudanças conforme for evoluindo sua aplicação, então
52
+
ela tem que ser simpática e amigável a ponto de voce nem ligar
43
53
que o jest rode na trigger de pos-commit.
44
54
45
55
Concentre nela os casos de uso, nela que será construído o seu negócio.
@@ -48,62 +58,90 @@ Concentre nela os casos de uso, nela que será construído o seu negócio.
48
58
49
59
É a cola que une as camadas externas com negócio (é você controller?).
50
60
51
-
Diferentemente do controller que foi projetado para arquitetura MVC e todo mundo já deixou alguma regra de negócio nele que eu sei e não adianta mentir, ele abstrai totalmente a ideia de ponte e pode ser aplicado em **qualquer contexto** dando uma flexibilidade grande para reaproveitamento de código.
61
+
Diferentemente do controller que foi projetado
62
+
para arquitetura MVC e todo mundo já deixou alguma
63
+
regra de negócio nele que eu sei e não adianta mentir,
64
+
ele abstrai totalmente a ideia de ponte e
65
+
pode ser aplicado em **qualquer contexto** dando uma
66
+
flexibilidade grande para reaproveitamento de código.
52
67
53
68
---
54
69
55
70
Importante ressaltar
56
71
57
-
* camada de negócios conversa com adapter;
58
-
* adapter conversa com ports; e
59
-
*~~camada de negócios fala com ports~~.
72
+
- camada de negócios conversa com adapter;
73
+
- adapter conversa com ports; e
74
+
-~~camada de negócios fala com ports~~.
60
75
61
76
---
62
77
63
-
O controller tinha responsabilidade de fazer ponte com a camada de modelo e ainda sanitizar os dados, preocupação que veremos na frente em **ports**.
78
+
O controller tinha responsabilidade de fazer ponte com a
79
+
camada de modelo e ainda sanitizar os dados,
80
+
preocupação que veremos na frente em **ports**.
64
81
65
-
Aqui já ocorre consumo de serviços que precisam ser simulados (mock, emulador de serviços), então por consequência ocorre também injeção de dependência, para que a solução permita entrar com mock com facilidade sem alterar o contexto da função. O teste unitário começa a ficar mais complicado e começa os testes de comportamento, pois no adapter você está claramente consumindo o serviço, mas consumindo de forma direta.
82
+
Aqui já ocorre consumo de serviços que precisam ser
83
+
simulados (mock, emulador de serviços), então por consequência ocorre
84
+
também injeção de dependência, para que a solução permita
85
+
entrar com mock com facilidade sem alterar o contexto da função.
86
+
O teste unitário começa a ficar mais complicado e
87
+
começa os testes de comportamento, pois no adapter
88
+
você está claramente consumindo o serviço, mas consumindo de forma direta.
66
89
67
90
### Ports
68
91
69
-
As bordas que dão a fama de arquitetura hexagonal, pois foi feito pra abstrair como um hexágono onde cada lado significa uma porta I/O.
92
+
As bordas que dão a fama de arquitetura hexagonal, pois foi feito pra abstrair
93
+
como um hexágono onde cada lado significa uma porta I/O.
70
94
71
95
Exemplos de ports:
72
96
73
-
* máquinas de estado (fila, banco de dados);
74
-
* handlers em lambda;
75
-
* serviço http com express; e
76
-
* log shipper.
97
+
- máquinas de estado (fila, banco de dados);
98
+
- handlers em lambda;
99
+
- serviço http com express; e
100
+
- log shipper.
77
101
78
-
Ele pode ser conectado ao ambiente real ou simulado, onde também ocorre injeção de dependência e o contexto da avaliação de comportamento foge do contexto das regras de negócio.
102
+
Ele pode ser conectado ao ambiente real ou simulado, onde também ocorre injeção de
103
+
dependência e o contexto da avaliação de comportamento
104
+
foge do contexto das regras de negócio.
79
105
80
-
Começa a ficar convidativo fazer ainda o BDD, mas com as portas podemos ir além, através de simulação de serviços como [localstack](https://localstack.cloud/) podemos chegar a simular alguns volumes de carga (não generosos por ser simulado e não ter o mesmo throughput de um ambiente real), e usar [Chaos Monkey](https://en.wikipedia.org/wiki/Chaos_engineering), isso é possível porque o localstack permite que você simule taxas de erros nos serviços para testes de resiliência.
106
+
Começa a ficar convidativo fazer ainda o BDD, mas com as portas podemos ir além,
107
+
através de simulação de serviços como [localstack](https://localstack.cloud/)
108
+
podemos chegar a simular alguns volumes de carga
109
+
(não generosos por ser simulado e não ter o mesmo throughput de um ambiente real),
110
+
e usar [Chaos Monkey](https://en.wikipedia.org/wiki/Chaos_engineering),
111
+
isso é possível porque o localstack permite que você simule taxas de erros
112
+
nos serviços para testes de resiliência.
81
113
82
-
Esse [projeto da Netflix](https://github.com/Netflix/chaosmonkey) pode ampliar seus serviços pra teste como banco de dados por exemplo.
114
+
Esse [projeto da Netflix](https://github.com/Netflix/chaosmonkey) pode ampliar
115
+
seus serviços pra teste como banco de dados por exemplo.
83
116
84
-
Na integração contínua o localstack é amigável para manter o mesmo ambiente em várias fases até chegar em produção passando por várias situações semelhante a serviços reais.
117
+
Na integração contínua o localstack é amigável para manter
118
+
o mesmo ambiente em várias fases até chegar em produção
119
+
passando por várias situações semelhante a serviços reais.
85
120
86
121
87
122
88
123
### Como usar esse projeto
89
124
90
125
É bem simples de já começar rodando
91
126
92
-
1. Configure o `.env` baseado no `.env.example`;
93
-
2. ligue o localstack com `docker-compose up -d`;
94
-
3. levante o ambiente demo usando [terraform](https://www.terraform.io/) com os comandos:
127
+
- Configure o `.env` baseado no `.env.example`;
128
+
- ligue o localstack com `docker-compose up -d`;
129
+
- levante o ambiente demo usando [terraform](https://www.terraform.io/) com os comandos:
130
+
95
131
```bash
96
132
$terraform init
97
133
$terraform plan (avalia se é isso mesmo que quer criar)
98
134
$terraform apply
99
135
```
100
-
4. instale as dependências com `yarn install`; e
101
-
5. rode o projeto com yarn start.
136
+
137
+
- Instale as dependências com `yarn install`; e
138
+
- Rode o projeto com yarn start.
102
139
103
140
Irá levantar uma instância de serviço http(Express), e seja feliz no consumo
104
141
105
142
## Features desse boilerplate
106
143
107
-
1. JsDoc implementado em todos os métodos e separados em namespaces na documentação que é gerado toda vez que aplica commit;
108
-
2. localstack como ambiente de simulação; e
109
-
3. Javascript ECMA 2015 com linters que te ajudam a manter o código funcional e puro.
144
+
- JsDoc implementado em todos os métodos e separados em namespaces
145
+
na documentação que é gerado toda vez que aplica commit;
146
+
- Localstack como ambiente de simulação; e
147
+
- Javascript ECMA 2015 com linters que te ajudam a manter o código funcional e puro.
0 commit comments