Folder-by-type funciona apenas em projetos de pequena escala. Pasta por característica é superior na maioria dos casos.

Folder-by-type está ok quando você tem apenas um pequeno número de arquivos (menos de 10 por tipo, digamos). Assim que você obtém vários componentes em seu projeto, todos com vários arquivos do mesmo tipo, fica muito difícil encontrar o arquivo real que você está procurando.

Portanto, pasta por característica é melhor devido à sua escalabilidade. No entanto, se a pasta por característica acabar perdendo informações sobre o tipo de componente que um arquivo representa (porque não está mais em uma pasta controller , por exemplo), isso também se torna confuso. Existem duas soluções simples para isso.

Primeiro, você pode seguir as convenções de nomenclatura comuns que implicam em typeness no nome do arquivo. Por exemplo, o popular guia de estilo do AngularJS de John Papa tem o seguinte:

Naming Guidelines

• Use consistent names for all components following a pattern that describes the component's feature then (optionally) its type. My
  recommended pattern is feature.type.js. There are 2 names for most
  assets:

  • the file name (avengers.controller.js)
  • the registered component name with Angular (AvengersController)

Em segundo lugar, você pode combinar estilos de pasta por tipo e de pasta a característica em pasta por característica, por tipo:

com.example
├── pet
|   ├── Controllers
│   |   ├── PetController1.java
|   |   └── PetController2.java
|   └── Services
│       ├── PetService1.java
│       └── PetService2.java
├── user
|   ├── Controllers
│   |   ├── UserController1.java
│   |   └── UserController2.java
|   └── Services
│       ├── UserService1.java
│       └── UserService2.java

Isso realmente não tem nada a ver com a tecnologia em questão, a menos que você use uma estrutura que force pasta por tipo em você como parte de uma abordagem de convenção sobre configuração.

Descobri que é mais fácil trabalhar com pacotes por característica por um motivo, principalmente:

Alta modularidade e coesão : torna mais fácil jogar com o escopo dos componentes. Podemos usar os modificadores de acesso para impor as invariantes do modelo de domínio e tornar todo o recurso altamente coeso como ( Lei de Deméter sugere.

Outras razões são:

• Navegação de código mais fácil
• Um nível mais alto de abstração
• Minimizar escopos (contextos delimitadores)
• Mais fácil de modularizar (adicionar / excluir mais recursos), manter e substituir.

Por outro lado, pasta por camada coloca muita ênfase nos detalhes da implementação, como @David mencionou. A pasta por camada pode ajudar a organizar o conteúdo dentro de pastas por característica .