| ... | @@ -16,6 +16,42 @@ |
... | @@ -16,6 +16,42 @@ |
|
|
<img src="uploads/df63c1ae8acde46d4d1f45f6ab1cd9a5/LogoCooperaRS.png" width="150">
|
|
<img src="uploads/df63c1ae8acde46d4d1f45f6ab1cd9a5/LogoCooperaRS.png" width="150">
|
|
|
</div>
|
|
</div>
|
|
|
|
|
|
|
|
|
O projeto _Coopera RS_ adota uma **arquitetura cliente-servidor**, dividindo a solução em dois componentes principais:
|
|
|
|
|
|
|
|
- **Cliente (Front-end):** Construído em _React_, responsável pela interface web e interação direta com o usuário.
|
|
|
|
- **Servidor (Back-end):** Desenvolvido em _Spring Boot_, lidando com as regras de negócio, integrações e persistência de dados.
|
|
|
|
|
|
|
|
No diagrama da figura 19, é possível observar que todo o ecossistema está executando dentro de contêineres _Docker_, provisionados em uma instância _Amazon EC2_ (AWS). Dessa forma, a aplicação front-end (React) e o back-end (Spring Boot) ficam encapsulados em contêineres separados, facilitando a escalabilidade e o isolamento de cada serviço.
|
|
|
|
|
|
|
|
A comunicação entre o front-end e o back-end acontece via requisições HTTP REST, seguindo o modelo tradicional de cliente-servidor. Quando o usuário acessa a aplicação web, as requisições são enviadas ao servidor _Spring Boot_, que processa as regras de negócio e interage com as bases de dados.
|
|
|
|
|
|
|
|
- **Integração com a AWS**
|
|
|
|
|
|
|
|
Alguns serviços da _Amazon Web Services_ (AWS) foram incorporados para dar suporte à aplicação:
|
|
|
|
|
|
|
|
- **Amazon S3:** Utilizado para armazenar arquivos estáticos, imagens ou qualquer conteúdo que necessite de um _bucket_ de alta disponibilidade e escalabilidade.
|
|
|
|
- **Amazon SES:** Responsável pelo envio de e-mails transacionais, como confirmações de cadastro, notificações de compras ou recuperação de senha.
|
|
|
|
- **Pipeline de Integração Contínua (CI) e Implantação Contínua (CD)**
|
|
|
|
|
|
|
|
O controle de versão e a automação de _deploy_ são realizados via **GitLab**. O fluxo ocorre da seguinte forma:
|
|
|
|
|
|
|
|
1. O desenvolvedor realiza um _commit_ ou _merge request_ no repositório do _GitLab_.
|
|
|
|
2. Um _GitLab Runner_ é acionado para executar testes e _builds_ da aplicação.
|
|
|
|
3. Caso seja aprovado, o runner gera as imagens _Docker_ do front-end e do back-end.
|
|
|
|
4. As imagens são enviadas para a instância _EC2_, onde são executadas como contêineres (ou atualizadas, em caso de uma nova versão).
|
|
|
|
|
|
|
|
Esse processo garante que todas as novas funcionalidades e correções sejam testadas antes de chegar ao ambiente de produção.
|
|
|
|
|
|
|
|
- **Padrão Arquitetural (Back-end)**
|
|
|
|
|
|
|
|
Para a camada de serviços, foi adotada uma abordagem inspirada na **Arquitetura Hexagonal**, também conhecida como _Ports and Adapters_. Essa arquitetura visa separar o núcleo de regras de negócio (o “domínio”) das partes externas de comunicação (banco de dados, serviços externos, interface web etc.). Dessa forma, as “portas” são as interfaces que definem como o domínio se comunica com o resto do sistema, enquanto os “adaptadores” implementam essas portas em tecnologias específicas (ex.: repositórios para acesso ao PostgreSQL, controladores REST para expor endpoints etc.).
|
|
|
|
|
|
|
|
Essa estrutura modular facilita:
|
|
|
|
|
|
|
|
- **Manutenção**: modificações em um adaptador (por exemplo, troca de banco de dados) podem ser feitas sem afetar diretamente o domínio.
|
|
|
|
- **Testabilidade**: cada camada pode ser testada isoladamente, garantindo maior confiabilidade do sistema.
|
|
|
|
- **Evolução**: novos serviços ou integrações podem ser adicionados sem grandes impactos no núcleo do projeto.
|
|
|
|
|
|
|
# Diagrama de Deploy
|
|
# Diagrama de Deploy
|
|
|
|
|
|
|
|
 |
|
 |
