Seguir a estrutura de pastas que o Angular-cli propõe é bom... se você só quiser criar uma réplica de uma calculadora dos anos 80. Mas se o projeto crescer, aí complica. Tentar manter tudo organizado em projetos grandes é como querer fazer um festival de música no porão da sua avó.

A estrutura do CLI

Quando você começa com o Angular-cli, ele te apresenta logo de cara o comando que parece mágico para criar componentes em série.

ng g component meu-novo-componente

O resultado? Uma bela bagunça:

|-- app
    |-- meu-novo-componente
        |-- meu-novo-componente.component.{html, scss, spec, ts}
    |-- meu-outro-componente
        |-- meu-outro-componente.component.{html, scss, spec, ts}

E, claro, você também pode criar módulos, diretivas, guards e mais algumas coisas. Porque quem não quer mais bagunça para gerenciar? No final, manter tudo assim vira uma receita para o caos. Services, pipes e directives brigando por espaço.

Prepare-se para o desastre:

|-- app
    |-- [+] componente-a
    |-- [+] componente-b
    |-- [+] interceptors
    |-- [+] mocks
    |-- [+] services
    |-- [+] header
    |-- [+] panel
    |-- [+] directives
    |-- [+] guard
    |-- [+] home
    |-- [+] login
    |-- [+] pipe

É uma mistura que só fica mais complicada conforme o projeto cresce.

Por que organizar as pastas do projeto?

A tal das "melhores práticas"... Elas realmente ajudam, tipo deixar um caminho mais fácil, mas a longo prazo. Melhorar a qualidade do software? Sim, uma bagunça organizada ainda é uma bagunça.

Crescimento

Com ela, sua vida supostamente fica mais simples. Adicionar novos componentes como se fossem cartas de baralho, tudo bem certinho.

Corrigir Bugs

Achar e corrigir bugs será tão claro quanto um campo minado. Encarar esses problemas vira uma tarefa difícil.

Um jeito diferente do CLI

Não tem solução mágica. Depende das funções e do tamanho do projeto. A estrutura vai mudar conforme o projeto cresce.

A estrutura

Aqui está a promessa de um projeto grande:

|-- modules
    |-- modulo1
        |-- [+] components
        |-- modulo1.service.ts
        |-- modulo1.module.ts
        |-- modulo1.routes.ts

    |-- modulo2 
        |-- [+] components
        |-- modulo2.service.ts
        |-- modulo2.module.ts
        |-- modulo2.routes.ts

|-- shared
    |-- [+] components
    |-- [+] mocks
    |-- [+] models
    |-- [+] directives
    |-- [+] pipes

|-- core
    |-- [+] authentication
    |-- [+] footer
    |-- [+] guards
    |-- [+] http
    |-- [+] interceptors
    |-- [+] mocks
    |-- [+] services
    |-- [+] header

|-- app.module.ts
|-- app.component.ts

Módulos - Lazy Load

Os módulos agora carregam de forma lazy. Dá a impressão de um aplicativo bem bonito, mas que demora um pouco para iniciar.

|-- pedido // Module
    |-- novo
        |-- novo-pedido.component.{html, scss, spec, ts}
    |-- editar
        |-- editar-pedido.component.{html, scss, spec, ts}
    |-- detalhes
        |-- detalhes-pedido.component.{html, scss, spec, ts}
    |-- pedido.service.ts
    |-- pedido.module.ts
    |-- pedido.routes.ts

Core

O core é tipo o chefe dos seus serviços singleton, o conector do seu aplicativo. Espera-se um pouco mais de ordem por aqui.

Shared

O shared é como um depósito comum. Todo mundo joga suas coisas lá para serem usadas por todos.

Conclusão

Não há solução mágica, apenas estruturas que dependem do destino do seu aplicativo. Até a versão 6 do Angular, que se atreveu a sair sem grandes mudanças nisso.

Referências