Arquitetura do Projeto

Arquitetura

Este documento tem como objetivo oferecer uma análise detalhada da arquitetura atual do projeto, com o intuito de identificar possíveis falhas de design e projeto, melhorar a facilidade de manutenção do sistema e otimizar os custos envolvidos. Por meio da avaliação da estrutura existente, iremos apresentar uma arquitetura recomendada, que contemplará representações abrangentes e elucidativas das diversas perspectivas relacionadas ao projeto.

Arquitetura As - Is

O projeto adota uma arquitetura de camadas, seguindo um padrão comum na indústria. Cada camada desempenha um papel específico no funcionamento do sistema. As camadas principais são:

• Front-end: Responsável pela interação com o usuário, apresentando a interface gráfica e permitindo a entrada de dados e a exibição de informações.

• Back-end: Responsável pelas operações do sistema, incluindo a lógica de negócios, processamento de dados e comunicação com outras partes do sistema ou serviços externos.

• Banco de Dados: Responsável pelo armazenamento e recuperação de informações utilizadas pelo sistema. É utilizado para persistir dados de forma estruturada, garantindo a integridade e a disponibilidade dos mesmos.

Além disso, é possível observar uma sub-arquitetura seguindo o padrão MVC (Model-View-Controller) na camada de front-end. Essa abordagem divide o sistema em três componentes:

• Modelo (Model): Responsável pela representação e manipulação dos dados, bem como pela lógica de negócios relacionada a eles.

• Visão (View): Responsável pela apresentação dos dados ao usuário, exibindo informações de forma adequada e interativa.

• Controle (Controller): Responsável pela intermediação entre a visão e o modelo, gerenciando as interações do usuário e coordenando as ações correspondentes no sistema.

Essa estrutura no padrão MVC ajuda a promover a separação de responsabilidades, facilitando a manutenção e a evolução do projeto ao longo do tempo.

Diagrama de Componentes

Link de Acesso à Imagem acima:Diagrama de Componentes

Módulo	Ação
Models
Controllers
utils
Middleware
Configs
Routes
Services
Pages
Componentes
Render
Database

Padrões de Software Utilizados

• Singleton: A biblioteca recoil é utilizada para armazenar o estado global da aplicação, sempre acessível por todas as páginas e componentes. A qualquer momento, só existe uma instância do gerenciador de estado, compartilhado por toda a aplicação. Esse padrão é utilizado em diversas partes da aplicação, e podem ser observados no diretório frontend/src/states/.

• Observer: Esse padrão é utilizado para monitorar mudanças nos dados e atualizar os componentes do front-end para refletir as mudanças — a renderização condicional de componentes permite a alteração dos dados exibidos com base no estado armazenado internamente por cada componente. São exemplos desse padrão as funcionalidades de esvaziar carrinho; o bloqueio do botão de ‘Confirmar pedido’ quando o carrinho está vazio; além da atualização de status do pedido, emitida pelo restaurante, que é refletida na tela vista pelo usuário.

• DAO: Os objetos da aplicação são armazenados em um modelo de dados padronizado para permitir a uniformização do acesso e escrita aos dados de uma forma unificada. Isso pode ser observado na pasta backend/src/models.

Arquitetura To - Be

Diagrama de Componentes Modificado

Link de Acesso à imagem acima: Modificação do Diagrama de Componentes

Foram sugeridas as seguintes modificações a fim de atender uma arquitetura ideal para o projeto.

Modificação	Justificativa
Remoção do Cabeçalho Admin de _frontend/src/componentes_	Criação de Apenas um cabeçalho que engloba tudo. Essa modificação serve para diminuir a quantidade de arquivos e trazer um padrão simples ao projeto.
Criação de um service para cada controller em _backend/src/services_	Serve para criar uma camada de abstração suficiente evitando a manipulação direta do banco de dados e o service poderá cuidar de validações evitando conflitos e centralizando acesso aos dados.

Padrões de Software Sugeridos:

• State: A lógica de status do pedido poderia utilizar melhor esse padrão para gerenciar a mudança da situação de um pedido. Assim, seria possível encapsular uma lógica diferente para cada estado possível, com funções de transição de um estado para outro (como gerar uma notificação para o usuário, ou permitir a operação “Confirmar entrega”, que só estaria disponível quando o status fosse “Saiu para entrega”), o que faciltaria a manutenção da lógica da aplicação.

• Command: A fila de pedidos a ser apresentada na cozinha pode ser implementada utilizando o padrão Command. Cada solicitação de pedido gera um comando para que o pedido entre numa fila, onde o primeiro pedido a ser feito é o primeiro a ser atendido. Do lado da cozinha, deve haver também um comando que libere o pedido para entrega uma vez que estiver pronto, gerando uma atualização no status do pedido.

• Strategy: As diferentes formas de pagamento podem utilizar o padrão Strategy, que consiste em criar subclasses intercambiáveis implementando diferentes lógicas para um mesmo processo. Assim, a lógica para pagamento via cartão poderia incluir uma lógica adicional para verificar se o cliente informou os dados do cartão ao criar a conta, e caso necessário, solicitar os dados do cartão; a lógica de pagamento por Pix incluiria a geração de um QR Code e a verificação automática de pagamento; e, por fim, o pagamento em dinheiro poderia solicitar a quantidade de troco a ser levada até o consumidor no ato da entrega.

• Composite: Os combos podem ser implementados utilizando o padrão Composite, que permite o encapsulamento de objetos “simples” (objetos únicos) ou “compostos” (coleções) uns dentro dos outros, de maneira uniforme. A entidade Combo poderia conter outros objetos do tipo Combo, ou objetos Produto. Assim, poderia haver um combo contendo alguns itens (por exemplo, duas bebidas), e este poderia tanto ser adicionado ao carrinho por si só, como estar contido em um outro combo maior (por exemplo, um combo com dois hambúrgueres e duas bebidas).

• Adapter: Esse padrão pode ser utilizado para simplificar a interação com os objetos a partir da criação de serviços de manipulação para cada tipo de dado, evitando a interação direta com o banco de dados. Assim, cada service criado pode cuidar de etapas como consulta, atualização, validação e persistência, implementando para isso qualquer lógica – simples ou complexa. Assim, todas as partes da aplicação que precisassem manipular um recurso específico o fariam através da mesma interface. Obs.: No momento, um service já está sendo utilizado na aplicação para as funcionalidades de login e carrinho. Porém, outros também poderiam ser criado para a manipulação dos demais componentes (produto, pedido etc.)

• DAO: Apesar de estar sendo usado no backend, também seria possível usufruir desse padrão no frontend, trazendo mais facilidade ao acesso de dados a cada objeto. Não existe, no momento, uma representação das estruturas Delivery, Item, Order e User no front-end — logo, caso alguma alteração seja feita no backend e novos campos sejam incluídos ou modificados, será dificíl atualizar o front-end para refletir essas mudanças.

Sugestões de uso de táticas para melhorar a performance e segurança da aplicação.

Para o projeto criado, as seguintes estratégias serão aplicadas de acordo com objetivo.

Performance

Armazenamento em cache: É aconselhável, para o projeto, utilizar o armazenamento em cache, principalmente nos dados que são acessados frequentemente, como o Cardápio e o Carrinho. Isso reduz a carga no banco de dados e aumenta a velocidade de resposta de aplicação.

Segurança de Aplicação