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.jsBaseado 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
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:
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: