Folder-by-type funziona solo su progetti su piccola scala. Folder-by-feature è superiore nella maggior parte dei casi.

Folder-by-type è ok quando si ha solo un piccolo numero di file (meno di 10 per tipo diciamo). Non appena si ottengono più componenti nel progetto, tutti con più file dello stesso tipo, diventa molto difficile trovare il file che si sta cercando.

Pertanto, la cartella per caratteristica è migliore a causa della sua scalabilità. Tuttavia, se si esegue una cartella per feature, si finisce per perdere informazioni sul tipo di componente rappresentato da un file (poiché non è più in una cartella controller , si dice), quindi anche questo diventa confuso. Ci sono 2 semplici soluzioni per questo.

In primo luogo, è possibile rispettare convenzioni di denominazione comuni che implicano la tipicità nel nome del file. Ad esempio la popolare guida allo stile di AngularJS di John Papa ha il seguente:

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)

In secondo luogo, puoi combinare stili cartella per tipo e cartella per caratteristica in cartella per tipo di funzionalità:

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

Questo in realtà non ha nulla a che fare con la tecnologia in questione, a meno che non si utilizzi un framework che impone la cartella per tipo su di te come parte di un approccio over-configuration della convenzione.

Personalmente, sono fermamente convinto che il folder-by-feature sia di gran lunga superiore e dovrebbe essere usato ovunque il più possibile. Raggruppa insieme le classi che funzionano effettivamente insieme, mentre folder-by-type copia semplicemente qualcosa che di solito è già presente nel nome della classe.

Ho trovato più facile lavorare con packages-by-feature per un motivo principalmente:

Elevata modularità e coesione : rende più facile giocare con l'ambito dei componenti. Possiamo utilizzare i modificatori di accesso per forzare gli invarianti del modello di dominio e rendere l'intera funzionalità altamente coesa come ( Legge di Demetra ) suggerisci.

Altre ragioni sono:

• Navigazione più semplice del codice
• Un livello più alto di astrazione
• Riduci a icona gli ambiti (contesti di delimitazione)
• Più facile da modulare (aggiungi / elimina più funzioni), mantieni e sostituisci.

D'altra parte, folder-by-layer pone troppa enfasi sui dettagli di implementazione, come menzionato da @David. Folder-by-layer può aiutare a organizzare il contenuto in folders-by-feature .