Pessoal,
saiu uma discussão aqui no trabalho sobre pacotes e camadas.
1 - Alguém afirmou que um pacote pode conter classes de diversas camadas,
2 - mas eu discordei: acho que um pacote deve estar SEMPRE contido em uma camada, ou seja os pacotes devem respeitar a arquitetura definida.
Um dos argumentos foi o de que em projetos da Caixa Econômica e Banco do Brasil as equipes definem pacotes que extrapolam as camadas, da primeira maneira. O q vcs acham?
Abraço.
Salve,
Bem na minha visão de arquitetura, e tudo que eu estudei sobre até agora, me faz a pensar que cada camada, até por questões de organização de código, deve estar em uma mesma estrutura de pacotes…
:pensativo:
Não entendi Marcos…
vc quis dizer que cada camada deve conter seus pacotes de maneira estanque!? Opção 1 ou 2? 8O
Não seria isto, bem caberia as duas idéias aí… tipo a parte de modelo de dados por exemplo poderia colocar assim:
com.portaljava.dao – algumas classes factory
com.portaljava.dao.news – classes dao para notícias
com.portaljava.dao.forums – classe dao para forumns
a parte de actions assim:
com.portaljava.web – algumas classes factory
com.portaljava.web.news – classes actions para notícias
com.portaljava.web.forums – classe actions para fóruns
:okok:
Em sua estrutura vc respeita a arquitetura com classes da camada Controller num pacote e classes da camada Acesso a Dados em outro, ou seja, o que está descrito na 2 opção…
A primeira opção, propõe que vc defina os pacotes por funcionalidades ou Casos de Uso. Ficaria dessa maneira:
com.portaljava.news - aqui todas as classes de todas as camadas que implementam news
com.portaljava.forums - aqui todas as classes de todas as camadas que implementam forums
Mais alguém? Continuo afirmando que é um grande equívoco contruir pacotes por funcionalidade (opção 1)…
Sua alternativa possui maior coesão, deve-se pensar em pacotes como componentes do sistema e caso você acumule muitas responsabilidades em um componente só ele perde coesão.
Um pacote, deve ter que mudar por apenas UM motivo. No caso o pacote muda porque a Camada X mudou. Se o pacote muda porque a Camada X mudou OU porque a Camada Y mudou temos um problema grave.
Aliás, muitos usam pacotes para representar Camadas em diagramas UML (principalmente em linguagens sem pacotes ou namespaces), apesar de eu costumar usar componentes.
Literatura recomendada: Page-Jones e Robert C. Martin.
Srs…
grato pela contribuição.
Além de tudo, essa abordagem (2) facilita o desenvolvimento e a padronização do código. Posso deixar um pacote com cada desenvolvedor e trabalhar com especialistas em cada camada…
A abordagem (1) gera problemas com gerenciamento de configuração pq posso ter 2, 3, N desenvolvedores trabalhando com as mesmas classes para implementar seus respectivos Casos de Uso.