1
resposta

Organização dos Pacotes do Projeto

Boa tarde.

Eu já tenho estudado sobre o Spring Framework a um tempo, em cursos fora da propria Alura, e agora vir estudar aqui na plataforma esta sendo muito bom, mas não posso deixar de perceber algumas diferenças em algumas formas de organizar os projetos.

Nos meus estudos passados, eu aprendi que uma organização de um projeto Spring deveria ser dividida da seguinte maneira:

Temos o src/main/.../api(nome do projeto) e aqui começam as divisões nos nossos pacotes:

  • Eu crio uma pasta so para os meus controllers (chamo de controller)
  • Crio uma pasta so para as minhas entidades (no caso do curso, Doctor e Patient)
  • Crio uma pasta so para os DTOS (e aqui crio subdivisões, como os DTOS de Doctor, Patient, Adress, etc)
  • E também uma pasta para os repositorys

Mas uma coisa curiosa, é que o professor deste curso faz as divisões de uma forma diferente. Ele cria sim uma pasta controller, mas ao inves de ter uma de entity, dto, etc, ele tem pastas de Medico e Paciente, e essas pastas tem todas as classes referentes a tal ... (nao sei como nomear, conjunto?)

Eu gostaria de saber, qual é a melhor forma de organizar o meu projeto, pq senti que no do professor é um pouco mais simples de organizar e se achar, mas no meu as divisões são feitas por responsabilidade.

Enfim, poderia me ajudar?

Valeu demais!

1 resposta

Oi Pedro!

São dois principais modelos de dividir os pacotes de uma aplicação:

  1. Package by Layer
  2. Package by Feature

O modelo que você está acostumado é o Package by Layer, no qual existe um pacote para cada camada da aplicação, como controller, service, model, dto, etc.

O modelo utilizado nesse curso foi o Package by Feature, no qual os pacotes são criados de acordo com as funcionalidades, como médico, paciente, consulta, etc.

Não existe um melhor do que o outro, pois cada um tem suas vantagens e desvantagens:

Package By Feature (Pacote por Funcionalidade)

Nesse modelo, os pacotes são organizados com base nas funcionalidades ou recursos do sistema. Cada pacote contém todas as camadas necessárias (como controle, serviço, modelo de dados, etc.) para implementar uma determinada funcionalidade. Por exemplo, se você tem um sistema de e-commerce, pode ter pacotes como "Autenticação", "Carrinho de Compras", "Pagamento", etc.

Vantagens:

  • Alta coesão: Os arquivos relacionados a uma funcionalidade específica estão agrupados em um único pacote, o que facilita a compreensão e a manutenção do código;
  • Baixo acoplamento: Os pacotes não estão fortemente acoplados uns aos outros, o que permite que uma funcionalidade seja modificada ou substituída sem afetar outras partes do sistema;
  • Escalabilidade: À medida que o sistema cresce, é mais fácil adicionar novas funcionalidades, pois elas são agrupadas em pacotes separados.

Desvantagens

  • Complexidade inicial: Pode haver um esforço adicional no início do projeto para definir e organizar corretamente os pacotes de acordo com as funcionalidades;
  • Possível duplicação de código: Se houver funcionalidades semelhantes em diferentes pacotes, pode ocorrer duplicação de código (o ideal é criar um pacote compartilhado nesse caso).

Package By Layer (Pacote por Camada)

Nesse modelo, os pacotes são organizados com base nas camadas da arquitetura, como a camada de apresentação, a camada de negócios e a camada de dados. Cada pacote contém todas as funcionalidades relacionadas a uma determinada camada, independentemente da funcionalidade em si. Por exemplo, você pode ter pacotes como "Controller", "Service", "Repository", etc.

Vantagens:

  • Separação clara de responsabilidades: Cada camada tem um pacote dedicado, o que facilita a compreensão e a manutenção do código, pois as responsabilidades são bem definidas;
  • Reutilização de código: Se várias funcionalidades usam a mesma camada, o código pode ser facilmente compartilhado entre elas, evitando duplicação;
  • Testabilidade: É mais fácil escrever testes unitários para cada camada separadamente, pois o código está agrupado em pacotes específicos.

Desvantagens:

  • Baixa coesão: O código relacionado a uma funcionalidade específica pode estar espalhado por várias camadas, dificultando a localização e a compreensão do código relacionado;
  • Maior acoplamento: As camadas estão fortemente acopladas entre si, o que pode levar a mudanças em uma camada afetando outras camadas;
  • ficuldade em adicionar novas funcionalidades: Adicionar uma nova funcionalidade pode exigir modificações em várias camadas diferentes, tornando o processo mais complexo.

Bons estudos!