Como organizar os pacotes da sua aplicação?

Pacotes devem ser totalmente estáveis ou totalmente instáveis. Por estável, quero dizer que o pacote tende a mudar menos. Pacotes estáveis são geralmente aqueles em que você coloca suas interfaces ou classes abstratas. Pacotes voláteis (ou instáveis) são aqueles onde queremos mudar. Geralmente guardamos as nossas classes de domínio, serviços e outras regras de negócio concretas lá. Essa separação é importante para facilitar a implementação do próximo princípio.

Pacotes devem sempre depender de pacotes mais estáveis do que ele próprio. A ideia é que cada pacote dependa sempre de pacotes mais estáveis do que ele próprio. Dessa forma, a propagação de mudanças é reduzida, e a manutenção torna-se mais fácil. Ou seja, os seus pacotes que contém regras de negócio (e é um pacote mais volátil) deve depender de pacotes mais estáveis, como o pacote onde você põe suas interfaces de acesso a dados (repositórios) ou mesmo as interfaces dos serviços que essas regras consomem (pacotes esses que são compostos por interfaces e, por consequência, são mais estáveis).

Resumindo, pense em deixar classes perto, ou para facilitar o reuso do pacote entre outros projetos, ou para agrupar classes que mudam juntas.

Veja que essas ideias também fazem sentido para classes, e foi o que discuti em meu post anterior sobre os princípios SOLID. Os princípios que comentei acima, aliás, também são discutidos pelo Robert Martin em seus livros e artigos.

Gerenciar dependências entre pacotes é tão trabalhoso quanto gerenciar dependências entre classes. Mas, sem dúvida, a longo prazo, o esforço se paga. Discutimos boas práticas de código em nosso curso presencial de arquitetura e design, em nosso livro sobre o assunto, e mesmo no meu livro e curso online sobre TDD.

E você, como tem separado seus pacotes? Usa alguma regra diferente das que mencionei aqui?