Open victorhcb opened 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
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
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
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):
/src
. Pensei em fazer isso pois separa um pouco nosso código da parte de infraestrutura e configuraçõesDú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)
Outro ponto sutil mas de extrema importância é a adição da pasta tests
. Nela iremos colocar nossos tests automatizados. A organização interna podemos decidir futuramente mas acho que deve seguir a estrutura de rotas da nossa API já que pelo menos inicialmente iremos fazer os testes de integração contra as rotas que construirmos.
Criei também uma pasta chamada database
(ela deve ir dentro de infra ou está bom aí?) e dentro dela adicionei uma pasta para migrations
, junto com alguns arquivos de configuração e conexão com o banco.
Bom... essas foram as mudanças que pensei ao longo da semana para que a gente possa revisar e discutir Vlwww
Bom... me rendendo a pasta infra pensei em algo mais ou menos assim:
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: