Folder-by-type or Folder-by-feature

Question

I make use of an AngularJS style guide. Within this guide there is a style called folder-by-feature, instead of folder-by-type, and I'm actually curious what's the best approach (in this example for Java)

Let's say I have an application where I can retrieve Users & Pets, using services, controllers, repositories and ofcourse domain objects.

Taking the folder-by-..... styles, we have two options for our packaging structure:

1. Folder-by-type

com.example
├── domain
│    ├── User.java
│    └── Pet.java
├── controllers
│    ├── UserController.java
│    └── PetController.java
├── repositories
│    ├── UserRepository.java
│    └── PetRepository.java
├── services
│    ├── UserService.java
│    └── PetService.java
│   // and everything else in the project
└── MyApplication.java

2. Folder-by-feature

com.example
├── pet
│    ├── Pet.java
│    ├── PetController.java
│    ├── PetRepository.java
│    └── PetService.java
├── user
│    ├── User.java
│    ├── UserController.java
│    ├── UserRepository.java
│    └── UserService.java
│   // and everything else in the project
└── MyApplication.java

What would be a good approach, and what are the arguments to do so?

Answer 1

Folder-by-type only works on small-scale projects. Folder-by-feature is superior in the majority of cases.

Folder-by-type is ok when you only have a small number of files (under 10 per type, let's say). As soon as you get multiple components in your project, all with multiple files of the same type, it gets very hard to find the actual file you are looking for.

Therefore, folder-by-feature is better due to its scalability. However, if you use folder-by-feature, you end up losing information about the type of component a file represents (because it's no longer in a controller folder, let's say), so this too becomes confusing. There are 2 simple solutions for this.

First, you can abide by common naming conventions that imply its type in the file name. For example, John Papa's popular AngularJS style guide has the following:

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)

Second, you can combine folder-by-type and folder-by-feature styles into folder-by-feature-by-type:

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

Answer 2

This really has nothing to do with the technology in question, unless you use a framework that forces folder-by-type on you as part of a convention-over-configuration approach.

Personally, I am strongly of the opinion, that folder-by-feature is far superior and should be used everywhere as much as possible. It groups together classes that actually work together, whereas folder-by-type just duplicates something that is usually already present in the class name.

Answer 3

Working with packages-by-feature stands out in high modularity and cohesion. It allows us to play with the components' scope. For example, we can use the access modifiers to enforce LoD and the dependency inversion for integrations or/and extensions.

Other reasons are:

• Easier code navigation
• A higher level of abstraction
• Minimize scopes (bounding contexts)
• Vertical modularization

Folder-by-layer puts too much emphasis on the implementation details, (as @David mentioned) which doesn't tells too much about the application we are working on. Unlike package-by-feature, package-by-layer encourage horizontal modularization. This sort of modularization makes working with cross-cutting components hard and tedious.

Finally, there's a 3rd option. Package by component which, in Uncle Bob's words, is aligned with his package principles. If Uncle's Bob opinion matters or not, I leave it to you to decide. I find it interesting since this convention is aligned with his Clean Architecture, which I like.