Estrutura de pastas de código

Todas as bases de código que eu já li ou trabalhei, compartilham uma estrutura de pastas similar:

Controladores
- BlogPostController
- CommentController
Modelos
- BlogPostModel
- ComentárioModelo
Views
- BlogPostsView
- BlogPostDetailView
Ajudantes
- …

All code bases I ever read or worked with, share a similar folder structure:

Controllers
- BlogPostController
- CommentController
Models
- BlogPostModel
- CommentModel
Views
- BlogPostsView
- BlogPostDetailView
Helpers
- …

Aquelas em que o desenvolvedor leu Domain Driven Design, ou está usando o Doctrine2 ou o Hibernate, geralmente têm um foco melhor no modelo de domínio:

Modelo
- Entidades
  - BlogPost
  - Comente
  - Do utilizador
- Repositórios
  - BlogPostRepository
  - CommentRepository
  - UserRepository
- Serviços
  - UserService
  - …

A filosofia dessas estruturas de pastas geralmente é inspirada nos frameworks que eles usam. Afinal, se o seu framework é organizado assim, deve ser uma boa prática, certo? Faz sentido realmente bom que um framework seja organizado em pacotes [módulos, componentes,…] como este.

Para sua aplicação, é uma oportunidade perdida. Você não está comunicando o papel que cada classe tem em relação aos outros, ou as dependências que possui. Um BlogPostRepository e um CommentRepository não têm relação direta um com o outro, além do fato de que ambos são Repositórios. No entanto, um BlogPostRepository tem uma dependência muito estreita no BlogPost.

BlogDomain
- BlogPost
  - BlogPost
  - BlogPostRepository
- Comente
  - Comente
  - CommentRepository
CoreDomain
- Do utilizador
  - Do utilizador
  - UserRepository

Isso torna muito mais fácil comunicar contextos limitados e ilustrar dependências. Por exemplo, o BlogDomain depende do CoreDomain. Em uma escala menor, o pacote BlogPost depende do pacote Comment. Aproximando ainda mais, o BlogPostRepository depende do BlogPost.

Em outras palavras: um BlogPost e um comentário sabem sobre seu autor. Um BlogPost tem zero ou mais comentários, mas os comentários não estão cientes de que eles pertencem ao BlogPost. Um BlogPostRepository gerencia entidades BlogPost, mas essas entidades não têm idéia de que estão sendo gerenciadas.

Obviamente, todo o exemplo é muito simples, como costumam ser os exemplos. O ponto é que, para manter o código limpo, é importante pensar muito sobre o acoplamento entre os elementos. Uma estrutura de pastas ajuda a delinear as depedências. A proximidade na árvore sugere um acoplamento mais próximo. A documentação pode ajudar ainda mais a explicar a direção do acoplamento. Podemos também decidir que os Comentários sabem sobre o BlogPost que eles também pertencem, mas isso deve ser uma decisão consciente.

Atualização de 18 de agosto de 2014: Eu ainda concordo com a ideia geral deste post, que é agrupar arquivos ou classes de acordo com a sua coesão no domínio e no modelo, ao contrário de seus padrões ou infra-estrutura subjacentes. No entanto, eu não usaria mais nomes como BlogDomain e CoreDomain. Seja qual for o seu domínio principal, ele pode mudar no futuro. As empresas evoluem. Autenticação pode ser um nome melhor. Eu também não usaria mais o sufixo “Domain”. E, finalmente, tentaria reduzir o acoplamento entre blogs e autenticação, por exemplo, compartilhando apenas um pequeno conjunto de Eventos de Domínio.

Fonte: @mathiasverraes