cujaunifesp / api.cujaunifesp.com

https://api-cujaunifesp-com.vercel.app
1 stars 2 forks source link

Arquitetura e organização das pastas #1

Open victorhcb opened 1 year ago

victorhcb commented 1 year ago

Gostaria de trazer para essa issue uma discussão muito importante sobre a arquitetura adotada para esse projeto. O ponto importante aqui é fazermos a escolha de um modelo que nos permita trabalhar com segurança e ao mesmo tempo garantir a constante manutenção e modificação do sistema. Escolha de estruturas engessadas e muito acopladas podem prejudicar o andamento do projeto no futuro.

Destaco aqui alguns pontos de reflexão que tive ao longo da semana sobre o início do projeto.

Monolito x Microsserviços

O primeiro ponto de análise que gostaria trazer é as duas possibilidades que temos para distribuição dos serviços de nossa api. É importante considerar o contexto do projeto: queremos desenvolver diversos serviços na tentativa de unificar os processos do CUJA e unir todos eles dentro de um único "ecossistema". A questão que fica é: devemos fazer isso através de um monolito grande e bem estruturado, modulado para separar bem as responsabilidade de cada serviço sem precisar dispor de diversas hospedagens e infraestruturas separadas para diferentes serviços ou através da arquitetura de microsserviços separado a responsabilidade de cada serviço de forma completamente isolada e usando a api.cujaunifesp.com apenas como uma API Gateway.

Seguem alguns artigos interessantes sobre a diferenças entre as duas arquiteturas, com suas vantagens e desvantagens:

image

Fonte da imagem: https://medium.com/@marcelomg21/arquitetura-de-microsservi%C3%A7os-bc38d03fbf64

MVC x MSC

Queria levantar duas possibilidades de arquitetura para o nosso projeto e consequente organização de pastas e modelagem. A primeira é o MVC (model-view-controller) trazendo uma estrutura extremamente simples, mas, se bem modelada, muito poderosa que pode sustentar o projeto por muito tempo; entretanto é preciso tomar cuidado pois nosso projeto é muito grande e amplo, trazendo muitas responsabilidades. A segunda opção é o MSC (model-service-controller) que traz uma camada intermediária entre os controllers e models: a camada de services, responsável pela lógica de negócio e casos de uso do nossos sistema.

Sintam-se a vontade para sugerir novas possibilidades de arquitetura e organização do projeto. Eu apenas trouxe duas que conheço e acredito se encaixarem no nossos projeto.

Seguem alguns artigos de referência interessantes sobre as duas arquiteturas:

victorhcb commented 1 year ago

Pensando no esquema de monolito que discutimos na última reunião, pensei em uma estrutura de pastas para o projeto. Vamos supor que tenhamos dois serviços construídos em nossa API: um de controle de usuários que possibilita o cadastro de membros e cadastro de alunos e um de controle de materiais que serão postados por professores (membros) através da API. Seguindo essa modelagem podemos propor a seguinte organização:

📦 root
 ┣ 📂 app                 
 ┣ 📂 services           
 ┃ ┣ 📂 users           
 ┃ ┃ ┣ 📜 students-registration.js
 ┃ ┃ ┗ 📜 members-registration.js
 ┃ ┗ 📂 classroom
 ┃   ┗ 📜 materials-registration.js
 ┗ 📂 models         
    ┣ 📜 students.js
    ┣ 📜 materials.js
    ┗ 📜 members.js

Baseado no modelo MSC:

app --> #pasta do next.js para controle de rotas (controllers) services --> #pasta para services. são subdivididos em subpastas de acordo com seu escopo para criar diferentes serviços models --> #pasta para os models de cada entidade. cada entidade representaria uma tabela do banco, sendo os models responsáveis pela comunicação de dados relacionados à entidade

Mesmo sendo o monolito, nessa estrutura fazemos uma modelagem que separa bem as responsabilidades de cada serviço, permitindo maior organização do código

Estrutura de rotas (nessa issue #3):

POST /v1/users-service/members     //Adicionar novo membro
POST /v1/users-service/students      //Adicionar novo estudante
GET /v1/users-service/students/{id}       //Obter estudante a partir de seu id
POST /v1/classroom-service/materials       //Adicionar novo material
GET /v1/classroom-service/materials       //Obter uma lista de materiais
GET /v1/classroom-service/materials/{id}       //Obter um material a partir do seu id
victorhcb commented 1 year ago

Falaa pessoal, tudo bem?

Andei pensando mais ainda sobre a estrutura de pastas... é um tema que não sai da minha cabeça por ser algo muito importante e que pode ditar o futuro do projeto. Encontrar uma arquitetura boa e simples é quase uma caça ao tesouro hehe mas vamos lá...

Desenvolvendo um pouco a ideia anterior pensei em uma possibilidade para a organização (dessa vez fiz no word mesmo então segue print):

image

O que mudou?

Dúvida cruel: a dúvida que fica é se devemos criar uma pasta infra para colocar coisas como database . Não gosto muito da organização de uma pasta infra mas talvez deixe mais organizado... não sei... e outra pergunta: essa pasta infra deveria ir dentro de /src ou na pasta root mesmo? Talvez eu não separaria isso por enquanto e deixaria a própria root com a respnsabilidade de infraestrutura e configurações... afinal onde está o limite entre o que é infra e o que não é? (brisei legal hahaha espero que tenha conseguido me explicar)

image

Bom... essas foram as mudanças que pensei ao longo da semana para que a gente possa revisar e discutir Vlwww

victorhcb commented 1 year ago

Bom... me rendendo a pasta infra pensei em algo mais ou menos assim:

image