Eu pensei sobre isso um pouco atrás e recentemente reapareceu enquanto minha loja estava fazendo seu primeiro aplicativo Java real da web.
Como introdução, vejo duas estratégias principais de nomenclatura de pacotes. (Para ser claro, não estou me referindo a toda a parte 'domain.company.project' disso, estou falando sobre a convenção de pacote abaixo dela.) De qualquer forma, as convenções de nomenclatura de pacote que vejo são as seguintes:
Funcional: Nomear seus pacotes de acordo com sua função arquitetônica, em vez de sua identidade de acordo com o domínio do negócio. Outro termo para isso pode ser nomear de acordo com 'camada'. Portanto, você teria um pacote * .ui e um pacote * .domain e um pacote * .orm. Seus pacotes são fatias horizontais em vez de verticais.
Isso é muito mais comum do que a nomenclatura lógica. Na verdade, acho que nunca vi ou ouvi falar de um projeto que faça isso. É claro que isso me deixa desconfiado (mais ou menos como pensar que você encontrou uma solução para um problema de NP), pois não sou muito inteligente e presumo que todos devem ter grandes motivos para fazer isso da maneira que fazem. Por outro lado, não me oponho a que as pessoas simplesmente sintam falta do elefante na sala e nunca ouvi um argumento real para nomear pacotes dessa maneira. Parece ser o padrão de fato.
Lógico: Nomear seus pacotes de acordo com sua identidade de domínio de negócios e colocar todas as classes relacionadas a essa fatia vertical de funcionalidade nesse pacote.
Eu nunca vi ou ouvi isso, como mencionei antes, mas faz muito sentido para mim.
Tenho a tendência de abordar os sistemas verticalmente em vez de horizontalmente. Eu quero desenvolver o sistema de processamento de pedidos, não a camada de acesso a dados. Obviamente, há uma boa chance de tocar na camada de acesso a dados no desenvolvimento desse sistema, mas a questão é que não penso nisso dessa forma. O que isso significa, é claro, é que quando eu receber um pedido de alteração ou quiser implementar algum novo recurso, seria bom não ter que procurar em um monte de pacotes para encontrar todas as classes relacionadas. Em vez disso, eu apenas olho no pacote X porque o que estou fazendo tem a ver com o X.
Do ponto de vista do desenvolvimento, considero uma grande vitória ter seus pacotes documentando seu domínio de negócios em vez de sua arquitetura. Eu sinto que o domínio é quase sempre a parte do sistema que é mais difícil de entender, já que a arquitetura do sistema, especialmente neste ponto, está quase se tornando comum em sua implementação. O fato de eu poder chegar a um sistema com este tipo de convenção de nomenclatura e, instantaneamente, a partir da nomenclatura dos pacotes saber que ele lida com pedidos, clientes, empresas, produtos, etc., parece muito útil.
Parece que isso permitiria que você aproveitasse muito melhor os modificadores de acesso do Java. Isso permite que você defina interfaces de maneira muito mais limpa em subsistemas, em vez de em camadas do sistema. Então, se você tem um subsistema de pedidos que deseja que seja transparentemente persistente, você poderia, em teoria, nunca deixar que ninguém soubesse que é persistente, não tendo que criar interfaces públicas para suas classes de persistência na camada dao e, em vez disso, empacotando a classe dao em com apenas as classes com as quais lida. Obviamente, se você quiser expor essa funcionalidade, poderá fornecer uma interface para ela ou torná-la pública. Parece que você perde muito disso por ter uma fatia vertical dos recursos do seu sistema divididos em vários pacotes.
Suponho que uma desvantagem que posso ver é que isso torna a remoção de camadas um pouco mais difícil. Em vez de apenas excluir ou renomear um pacote e, em seguida, colocar um novo no lugar com uma tecnologia alternativa, você precisa entrar e alterar todas as classes em todos os pacotes. No entanto, não vejo que seja grande coisa. Pode ser por falta de experiência, mas eu tenho que imaginar que a quantidade de vezes que você troca de tecnologia empalidece em comparação com a quantidade de vezes que você entra e edita fatias de recursos verticais em seu sistema.
Então eu acho que a pergunta seria para você, como você nomeia seus pacotes e por quê? Por favor, entenda que não acho necessariamente que tropecei na galinha dos ovos de ouro ou algo assim aqui. Sou muito novo em tudo isso, principalmente com experiência acadêmica. No entanto, não consigo detectar as lacunas em meu raciocínio, então espero que todos vocês possam para que eu possa seguir em frente.