9. Arquitetura To Be
Nesta página, será apresentada uma documentação acerca da arquitetura do projeto como será. O principal propósito é oferecer uma explicação sobre as oportunidades arquiteturais identificadas assim como propor alterações visando melhorar a manutenção, escalabilidade e organização do código corrente.
Serão abordados aspectos como a estrutura do projeto e suas interdependências, arquitetura e padrões relevantes.
Atualmente, apenas o lado cliente compõe o projeto e por isso este documento detalha apenas as propostas que atuam diretamente no frontend. Existem outros padrões de projeto e estilos arquiteturais que auxiliam a manter a coesão no lado do servidor, porém, a escolha dessas tecnologias dependem das necessidades da implementação do projeto. Sugerimos a seguir algumas medidas baseadas nas documentações do projeto.
-
Estilo de Arquitetura
- Monolítica: Manter uma estrutura monolítica pode ser vantajoso a curto prazo, visto que o projeto tem um escopo pequeno e a arquitetura facilita debugar o código.
- Microsserviços: Por outro lado, a arquitetura de microsserviços também seria vantajosa caso o foco seja agilidade, por sua natureza distribuída.
- Client-Server: Para todos os fins, recomendamos a arquitetura Client-Server em conjunto com alguma outra. Essa arquitetura consiste na separação do código do frontend e backend, o que será essencial para escalabilidade e manutenção desse projeto.
-
Segurança
- Autenticação: Compreendendo o contexto do projeto e a noção de que não haverão conteúdos particularmente sensíveis no sistema, nossa recomendação é que seja mantida a simplicidade na segurança e que haja autenticação nos privilégios de forma segura.
Durante a análise do projeto, foi identificado a ausência de uma arquitetura relevante, o que nos convida a propor uma pela primeira vez. Dado a natureza web e sua stack previamente conhecida (contém React), é favorável seguir uma arquitetura que esteja conforme a base em que estamos trabalhando.
Popularizado pelo Facebook, a arquitetura Flux foi criada pensando no React, com as ideias de stores e a propagação da renderização, o que faria dela uma arquitetura essencial. Contudo, essa arquitetura faz parte da filosofia do React por padrão, ou seja, ela é a maneira com que interagimos com o React e não será tão útil explicitamente.
Observando a base mais de perto, notamos também redundâncias, oportunidades para componentização, que é uma característica do React. Reutilização de código é também importante para escalabilidade, assegurando que o mesmo código não precise ser alterado em diversos pontos na base.
Pela ideia proposta acima o estilo de arquitetura indicada será o Baseado em Componentes, amplamente utilizado no desenvolvimento de software para criar sistemas complexos e escaláveis, que está conforme a ideia de componentização. Esse estilo é baseado na ideia de decompor um sistema em componentes independentes, cada um responsável por uma funcionalidade específica.
- Decomposição: O sistema é dividido em componentes discretos, onde cada componente representa uma unidade funcional bem definida. Cada componente encapsula seu próprio estado interno e comportamento, promovendo a modularidade do sistema, o que facilita o desenvolvimento, a manutenção e a evolução do software.
- Reutilização: Os componentes são projetados para serem independentes e reutilizáveis, ajudando assim na economia de tempo e esforço de desenvolvimento.
- Interface: Cada componente expõe uma interface clara e bem definida, que especifica como os outros componentes podem interagir com ele. Isso promove o baixo acoplamento entre os componentes.
- Comunicação: Os componentes se comunicam uns com os outros por meio de mensagens ou chamadas de método. A comunicação pode ser síncrona ou assíncrona, dependendo dos requisitos do sistema.
- Gerenciamento de estado: Cada componente é responsável por gerenciar seu próprio estado interno. Isso garante que os componentes sejam independentes e possam ser facilmente substituídos ou atualizados sem afetar o restante do sistema.
| Componentes | Elementos |
|---|---|
| Footer | 4 |
| Lista | 4 |
| Forms | 3 |
| Forms* | 1 |
Com os novos componentes criados durante a componentização, podemos escolher também padrões de projeto para auxiliar nas possíveis interdependências que serão geradas. Sugerimos dois padrões em especial para melhor adaptação após as alterações.
- Decorator: Poderá ser útil no acoplamento de novos comportamentos aos componentes.
- Observer: Poderá ser útil na propagação de estados entre componentes.
Organização de diretórios não são preocupações da arquitetura de um projeto, porém, compreendendo que projeto atual, além de conter códigos descontinuados, é também ausente de uma convenção de nomenclatura, percebemos que há potencial de interferir de alguma forma com a conformidade do projeto com a nova arquitetura a longo prazo.
Utilizando o estilo de arquitetura Baseado em Componentes, temos como objetivo uma melhor reformulação e compreensão da estrutura de cada página-componente. Códigos duplicados entre páginas se tornarão componentes compartilhados, por exemplo. Dessa forma conseguiremos manter a estrutura do repositório mais limpa e escalável.
my-app/
|
|- public/ …
|
|- src/
| |- App.css
| |- App.js
| |- Contato.js
| |- Home.js
| |- Login.js
| |- Sala.js
| |- Teste.js
| |- index.cxx
| |- index.js
| |- logo.svg
| |- reportWebVitals.js
| |- setupTest.js
| |- style.css
|
| …
frontend/
|
|- public/ …
|
|- src/
| |- _test_/
| |- components/
| |- formTeste/
|
| |- pages/
| |- teste/
| |- Teste.js
|
| |- components/
| |- header/
| |- Header.js
|
| |- footer/
| |- Footer.js
|
| |- list/
| |- List.js
|
| |- form/
| |- formLogin/
| |- FormLogin.js
| |- formContato/
| |- FormContato.js
|
| |- pages/
| |- Home.js
| |- Contato.js
| |- Login.js
| |- Teste.js
| |- Sala.js
|
| |- App.js
| |- App.css
| |- index.js
| |- index.css
| |- style.css
|
| …
Veja abaixo o diagrama de pacotes da arquitetura proposta:
