Eu pessoalmente odeio noems de pacotes longos e ilegíveis, e tenho que conviver com eles. A convenção da Sun é boa, mas acho que peca no tamanho que algo pode atingir, principalmente se você considerar que a maioria das emrpesas brasileiras (e de outros lugares do mundo) vai usar sufixos/prefixos como o ‘.br’ a mais.
A idéia de manter <domínio de empresa>.<modulo> é boa, apesar de gerar pacotes grandes ela é um modo simples e precvisível. Se você conseguir abreviar o nome dos módulos, melhor ainda, apesar de que vários prefixos pequenos e vários prefixos grandes dá no mesmo: são horríveis. Mantenha o mínimo possível.
Note, entretanto, que você não precisa repetir uma estrutura de pacotes em cada módulo. Módulos que usem hierarquia de classes semelhantes devem utilizar pacotes genéricos de sua aplicação, como <domínio da empresa>.persistencia, ou <dominio de empresa>.conectores. Você também pode colocar classes em pacotes iguais em módulos se seu ConectorComCafeteiraWallita só é usado em um módulo, você pode mantê-lo em <dominio de empresa>.conectores, mesmo que seu fonte esteja junto aos fontes do módulo X (é um conector e apesar de ser usado hoje só no módulo X, não rpecisa ser acoplado á ele).
Já que estamos falando em padrões e arquiteturas, o conceito de módulo é um pouco confuso, e guarda muita carga de arquiteturas cliente/servidor e/ou procedurais. Dê uma olhada na literatura de componentes
Não use prefixo br.com para todos os seus pacotes. Isto foi uma bobagem que um cara da Sun escreveu e um monte de gente segue copiando sem pensar. Apenas use nome_do_projeto como prefixo ou quando muito nome_da_empresa.nome_do_projeto como prefixo.
