# Arquitetura

Foi escolhido o modelo C4 de documentação para arquitetura de software. Esse modelo consiste em um conjunto hierárquico de diagramas de arquitetura de software para contexto, containers, componentes e código.

A hierarquia dos diagramas C4 fornece diferentes níveis de abstração e cada um deles é relevante para um público alvo.

O motivo da escolha desse modelo é devido a sua facilidade de desenvolvimento e entendimento pelas partes envolvidas.

### Nível 1 - Diagrama de Contexto do Sistema
O diagrama de contexto mostra o sistema que está sendo construído. No diagrama, todos os usuários fazem uso de uma mesma aplicação, sendo seu fluxo de execução distinguido internamente. A aplicação por sua vez faz as requisições para a API.

![Screen_Shot_2020-07-03_at_12.03.14](uploads/90e59a27015623fbf51b355edd42d9f1/Screen_Shot_2020-07-03_at_12.03.14.png)

Figura 1: Diagrama de contexto

### Nível 2 - Diagrama de Container 
O diagrama de container amplia o sistema de software e mostra os containers (aplicativos, armazenamentos de dados, serviços, etc.) que compõem esse sistema de software. 
Aqui já é possível ver algumas decisões de tecnologias, decisões de arquitetura e a comunicação entre os serviços.


![Diagrama_de_Conteiner](uploads/e46226099380551bfd88acdb6c2f5574/Diagrama_de_Conteiner.png)

Figura 2: Diagrama de container

### Nível 3 - Diagrama de Componentes 
O diagrama de componentes amplia um container individual para mostrar os componentes dentro dele.

A seguir, na figura 4, é apresentado um exemplo da arquitetura interna do aplicativo e onde ocorre a comunicação com o servidor.
Na figura 5 é a arquitetura do servidor (API) e sua comunicação com o banco de dados e o retorno para o cliente.

![Screen_Shot_2020-07-03_at_12.26.07](uploads/046135dfa46219e8a065ceb5034dc0c0/Screen_Shot_2020-07-03_at_12.26.07.png)

Figura 3: Diagrama de componente: comunicação API, banco de dados e aplicativo

![Diagrama_de_Contexto_1_](uploads/368a0223c858b969b10080d3d0da29a3/Diagrama_de_Contexto_1_.png)

Figura 4: Diagrama de componente: comunicação API, banco de dados e aplicação

### Nível 4 - Código e Padrões de Arquitetura
O último nível é o 4. Aqui a arquitetura é detalhada a nível de código e implementação.
O padrão de arquitetura utilizada foi o de cliente-servidor em conjunto com a arquitetura REST para a construção da api e a integração com o frontend.


O modelo de cliente-servidor é uma estrutura de aplicação distribuída que distribui as tarefas e cargas de trabalho entre os fornecedores de um recurso ou serviço, designados como servidores, e os requerentes dos serviços, designados como clientes.

O objetivo desta divisão é separar a arquitetura e responsabilidades em dois ambientes. Assim, o cliente (consumidor do serviço) não se preocupa com tarefas do tipo: comunicação com banco de dados, gerenciamento de cache, log, etc. E o contrário também é válido, o servidor (provedor do serviço) não se preocupa com tarefas como: interface e experiência do usuário. Permitindo, assim, a evolução independente das duas arquiteturas.


A API, implementada em node.js, é a responsável por tratar os dados e fazer a conexão das informações entre a aplicação web (frontend) e o banco de dados. A organização foi pensada em três camadas: Routes, Controllers.

![Diagrama](uploads/5429f0394c94134ddfd65b3f5695c61e/Diagrama.png)

Figura 5: Organização da API em Routes, Controllers

A camada de Routes é composta por todas as rotas da API que são expostas aos clientes para fazer a conexão via HTTP. A camada de Controller é a responsável pela lógica de negócio da aplicação. Toda rota definida em Router possui uma instância de Controller associada, responsável por sua lógica de negócio.

Para a aplicação web, implementada com o framework React, foi seguido o padrão de Component Based Architecture (Arquitetura Baseada em Componentes).

A organização foi pensada a partir do conceito de web components, onde cada "parte" da tela é um componente independente, customizável e que pode ser reutilizável em qualquer outra parte da aplicação. No exemplo a seguir, temos um exemplo da utilização de componentes no projeto representado como uma "árvore", tal qual a estrutura de dados. 

![arch_react](uploads/3627cd037e2154eba21c1f82e68dc23e/arch_react.png)

Figura 6: Representação de web components

Este tipo de arquitetura encapsula partes individuais de uma interface (componentes) em sistemas independentes e auto-sustentáveis.
Para o uso dessa arquitetura, os componentes precisam:
- Ser independentes;
- Interagir com outros componentes no mesmo espaço, sem afetar ou ser afetado pelo outro;
- Possuir sua própria estrutura, métodos e atributos;
- Ser reutilizável em qualquer outro lugar da aplicação.