Arquitetura do Sistema

Descrição

Esta seção irá abordar a arquitetura selecionada para o Backend e Frontend, além dos dados relativos ao deploy.

Sumário

• Arquitetura do Sistema
  • Descrição
  • Sumário
  • Arquitetura Geral da Aplicação
  • Deploy
    • Recipes API
    • Diagrama de Deploy
  • Backend
    • Definições de Tecnologias
    • Módulos do Sistema
    • Diagrama de Fluxo
    • Diagrama do Sistema
    • Diagramas de Sequência
  • Frontend
    • Definições de Tecnologias
    • Módulos do Sistema
    • Diagramas de Componentes
    • Diagrama do Sistema
    • Diagramas de Sequência
    • Diagramas de Fluxo de Telas

Arquitetura Geral da Aplicação

Uma visão geral sobre o entendimento de como a aplicação funciona, onde as diferentes camadas comunicam-se entre si, enviando e recebendo dados/requisições.

Deploy

Recipes API

A API de Receitas do projeto, está configurada para realizar entrega automática (Continuous Delivery) a cada commit realizado na brach de dev utilizando o Runner do Gitlab. Esta configuração é feita através do arquivo .gitlab-ci.yml. Após o commit, testes na aplicação são realizados e em caso de sucesso, uma imagem Docker é construída para que o serviço na máquina EC2 do projeto Olive na AWS da AGES passe a executá-la.

Esse processo é apresentado nesse vídeo: Ages 2021 - Configurando CI/CD com Gitlab

Diagrama de Deploy

Backend

Definições de Tecnologias

Pontos-chave:

• Questionário inicial para o time.
• Por questão de facilidade no desenvolvimento do projeto (em relação tanto ao backend quanto ao frontend), a linguagem definida foi Javascript.

Escolhas:

• Linguagem: JavaScript com TypeScript
• Frameworks: Node e Express
• knex como ORM
• celebrate como middleware de requests
• jest para testes unitários / integração

Módulos do Sistema

• Handlers: Responsável por manipular os possíveis erros/sucessos existentes, assim como as respostas da API para determinadas requisições feitas.

• Controllers: Aqui estão os arquivos que irão processar o que foi recebido pelo routes e chamar os métodos adequados dos services retornando uma resposta válida para o routes, normalmente em formato JSON

• Services: Nesta pasta ficam os arquivos que validam nossas regras de negócio, como a descrição detalhada para cada uma das receitas utilizando o repository para fornecer os dados do banco e realizar as validações, garantindo que todos os campos de uma receita foram preenchidos e que as receitas possuem uma tag identificadora para saber se foi aprovada ou não.

• Repositories: Todos os arquivos aqui fazem as chamadas ao banco de dados através dos models passando os parâmetros adequados para as funções desejadas.

• Models: Aqui estão todas as representações das tabelas do nosso banco de dados, mas de uma forma com que possamos trabalhar facilmente no código: classes. Os dados são recuperados do banco e convertidos para as classes criadas.

• Database: Aqui estão todas as migrations para o banco de dados, além do arquivo de tags para serem inseridas através do knex e do arquivo de conexão do banco.

Diagrama de Fluxo

Diagrama do Sistema

Diagramas de Sequência

Frontend

Definições de Tecnologias

Escolhas:

• Linguagem: Javascript
• Framework: React JS com Material UI
• Ferramentas: Prettier, ESLint.

Depois de conversas com os Stakeholders e discussões com o time em relação a tecnologias e conhecimentos de cada um para o projeto, foi concluído que JavaScript com a utilização de React seria ideal para a criação da aplicação a ser desenvolvida.

React.js é uma biblioteca de JavaScript, open source, utilizada para construir user interfaces, nomeadas para aplicações de página única.

O diferencial do React é ser rápida, escalável e simples, podendo ser usada com outras bibliotecas ou frameworks de JavaScript.

Prettier e ESLint são ferramentas voltadas para a padronização de código, a primeira sendo utilizada para formatação do mesmo e a segunda para identificar padrões e garantir o uso de boas práticas. Quando configuradas em uma IDE, elas garantem que ao salvar trechos do código, padrões de indentação, aplicação de boas práticas e formatação sejam seguidas.

Módulos do Sistema

• Components: Onde estarão localizados os componentes visuais encontrados em diferentes páginas da aplicação. Os componentes em sua maioria são genéricos e podem ser utilizado em mais de uma parte do sistema.
• Pages: Onde estarão localizadas as telas da aplicação. Cada tela é composta de diversos componentes que quando agrupados fornecem as funcionalidades da aplicação ao usuário.
• Routes: A camada de rotas da aplicação.
• Context: Onde é disponibilizado uma forma de passar dados entre a árvore de componentes sem precisar passar props manualmente em cada nível. É indicado para compartilhar dados que podem ser considerados “globais” para a árvore de componentes do React.
• Constants: Classe em que se encontramos temas relacionados à aplicação no geral, e que podem ser reaproveitados sempre, como fontes de tipografia e paleta de cores definidas para serem usadas.
• Assets: Pasta com as imagens que são utilizadas na aplicação uma ou mais vezes.

Diagramas de Componentes

O diagrama de componentes da aplicação apresenta a maneira com que as classes do sistema estão organizadas, levando em consideração suas interfaces, dependências e componentes criados.

Uma forma de ajudar a entender as diversas relações que o sistema possui é criando/projetando diagramas para compreender estas relações. Primeiro vamos partir por exemplo de um nível mais profundo na aplicação, demonstrando como ocorre essas relações dentro de um componente.

A imagem apresentada pode nos auxiliar no entendimento de como se comportam os componentes dentro do React. Claro, essa não é uma ideia definitiva mas sim uma concepção das possíveis relações existentes. Uma outra abordagem que poderíamos analisar é a presença apenas de campos como Name, Props,State e Functions, pois se um componente possuir outro componente filho ou nodos dentro de si, os mesmos podem ser acessados ao usar um props.children por exemplo.

Na imagem acima temos o que seria a representação para compreender a forma como os componentes conseguem se relacionar uns com os outros através das Props que foram descritas acima.

Aplicando esse conceito de representação para o nosso projeto, nós teremos um Diagrama de Componentes organizados da seguinte maneira:

Diagrama do Sistema

É a maneira como as camadas do sistema se comunicam, em outras palavras, uma representação do comportamento da aplicação como um todo. Um conjunto de componentes (implementados de forma genérica) compõe uma tela. Esta tela então é chamada pela Routes para assim compor o fluxo de telas da aplicação.

Pensando agora de maneira mais técnica e entrando mais afundo no código, o sistema é estruturado da seguinte maneira:

• O arquivo Routes é responsável por realizar o que chamamos de renderização
• Após acessar a aplicação (ocorrendo uma autenticação de usuário) as diversas Pages presentes na aplicação são apresentadas ao usuário.
• Para acessar as páginas existentes, uma rota é especificada para cada uma delas.

Por exemplo, caso o usuário deseje acessar a parte de Criações de uma Receita, é necessário que o caminho que ele faça na aplicação tenha uma rota que leve para /creations

Neste diagrama de sistema abordamos exatamente o que foi explicado acima, onde a Routes (através do react-router) manipula os diversos caminhos da aplicação, sendo que caso o desejo seja acessar a página responsável pelo Feed, é necessário que o seu path seja igual à /recipes. Também é demonstrado a forma como se comunicam as estruturas do sistema, onde uma página chama diversos componentes ou um único componente que, dentro de si, chama outros componentes.

Diagramas de Sequência

O Diagrama de sequência é uma abordagem na modelagem em UML na qual o objetivo é incidir sobre as linhas da vida existentes na aplicação. Em outras palavras, é uma espécie de diagrama de interação, pois descreve como e em qual ordem os diversos pacotes de trabalho trabalham juntos.

Diagramas de Fluxo de Telas