|
|
|[Página Inicial](home)|
|
|
# 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.
|
|
|
# Página da Arquitetura do Sistema
|
|
|
|
|
|
|
A hierarquia dos diagramas C4 fornece diferentes níveis de abstração e cada um deles é relevante para um público alvo.
|
|
|
Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto, Como:
|
|
|
|
|
|
|
O motivo da escolha desse modelo é devido a sua facilidade de desenvolvimento e entendimento pelas partes envolvidas.
|
|
|
* Segurança
|
|
|
|
|
* Rotas de Backend (Arquitetura
|
|
### Nível 1 - Diagrama de Contexto do Sistema
|
|
|
funcional)
|
|
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.
|
|
|
* Objects – Backend API
|
|
|
|
|
* Methods – Backend API
|
|
|
|
|
* Arquitetura Não Funcional)
|
|
Figura 1: Diagrama de contexto
|
|
|
* Diagrama de Pacotes / Componentes
|
|
|
|
|
(Arquitetura de software)
|
|
### Nível 2 - Diagrama de Container
|
|
|
* Diagrama de Deploy
|
|
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.
|
|
|
* Documentação sobre aplicação de
|
|
Aqui já é possível ver algumas decisões de tecnologias, decisões de arquitetura e a comunicação entre os serviços.
|
|
|
Design do Projeto
|
|
|
|
|
* Análise dos principios SOLID
|
|
|
|
|
* Code Review
|
|
|
|
|
*
|
|
Figura 2: Diagrama de container
|
|
|
Devem ser apresentados das seguintes formas:
|
|
|
|
|
|
|
### Nível 3 - Diagrama de Componentes
|
|
|
* Imagens ou Gifs
|
|
O diagrama de componentes amplia um container individual para mostrar os componentes dentro dele.
|
|
|
* Diagramas ou Sistemas
|
|
|
|
|
* Descrições ou Textos explicativos |
|
A seguir, na figura 4, é apresentado um exemplo da arquitetura interna do aplicativo e onde ocorre a comunicação com o servidor.
|
|
\ No newline at end of file |
|
Na figura 5 é a arquitetura do servidor (API) e sua comunicação com o banco de dados e o retorno para o cliente.
|
|
|
|
|
|
|
|
|
|
|
|
Figura 3: Diagrama de componente: comunicação API, banco de dados e aplicativo
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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. |
