A camada "Service" é quem faz a intermediação entre o model e o controller, né? Por que isso é benéfico? Por que não conectar diretamente o model com o controller? A professora disse que é porque o Sequelize montou o modelo muito engessado e fica sem ter como colocar regras de negócio. Por fica engessado?
Bom dia, Luidi! Tudo bem?
Além da particularidade apresentada pela instrutora, o fato de fazer a camada de abstração service é para concentrar toda a lógica da API em um só lugar.
Essa medida é feito seguindo boas práticas da programação, onde é pensando em segregar uma classe/arquivo para ter uma responsabilidade única no contexto da API, logo, quando em um momento distante, quando você precisar fazer uma mudança nessa lógica, será necessário alterar apenas aquela classe/arquivo.
Mas isso é apenas uma parte de um todo, caso queira entender melhor do que se trata essas boas práticas de programação, recomendo a leitura do artigo SOLID: o que é e quais os 5 princípios da Programação Orientada a Objetos (POO). Porém, já abro uma ressalva, que não será uma por norma sempre utilizar essas práticas em seu código, será algo de caso a caso.
Enfim, espero ter esclarecido e bons estudos!
Por que não seguir o SOLID cegamente? Isso não garantiria uma melhor organização e evitaria algumas refatorações? Tem algum exemplo prático que não seria benéfico seguir o SOLID à risca?
Oi, Luidi!
Porque cada princípio tem custo (mais camadas, mais arquivos, mais tipos) e nem sempre traz benefício proporcional no contexto. Use quando ele reduz acoplamento e facilita mudança; evite quando gera superengenharia e atraso sem ganho claro.
Casos práticos (quando NÃO seguir à risca)
Projeto pequeno / endpoint simples
Regra: se a lógica é trivial e pouco volátil, evite criar 3–4 camadas só para cumprir Single Responsibility e Interface Segregation.
Por quê: você incrimenta I/O cognitivo (mais arquivos/nomes) sem reduzir risco real.
Consulta altamente performática
Regra: quando precisar de um JOIN complexo/CTE que o ORM não otimiza bem, quebre a abstração e use uma raw query com índice certo.
Por quê: Liskov/Dependency Inversion via interfaces “bonitinhas” podem esconder custos e impedir o melhor plano de execução.
Modelo de domínio estável vs. regras efêmeras
Regra: se a “regra de negócio” é na verdade política temporária (ex.: feature flag, hotfix, promoção de 2 semanas), não crie 5 interfaces e 2 repositories; implemente no Service com guard clauses claras e remova depois.
Por quê: isolar tudo em abstrações perenes piora a rotatividade de código curto-vivo.
Interfaces granulares demais (I do SOLID)
Regra: se ISegregation levar a 5 interfaces quase idênticas para o mesmo repositório, una em 1 interface pragmática.
Por quê: excesso de contratos quebra o fluxo e não agrega segurança real.
Transactional boundary
Regra: orquestrações ACID com múltiplos modelos precisam de transação. Forçar cada passo a um Service distinto por SRP dispersa a transação. Concentre no Service agregador com transaction explícita.
Por quê: coerência > pureza de camadas.
Checklist objetivo (use isso na prática)
Um resumo em forma de pontos:
Fico à disposição.