Feature-oriented folder structure

In many applications the source code is split into the different layers that the application consists of from a technical architecture perspective. For example with a feature1 and feature2, the following could be the folder structure in a simple onion architecture:

src
- application
  - feature1
  - feature2
- domain
  - feature1
  - feature2
- web-client
  - feature1
  - feature2

This approach lays out the 3 layers application, domain and web-client, where each layer contains the relevant part of the features. While this can be a good way to ensure architectural consistency in the application, there are a few major drawbacks:

To remove a feature you have to edit each different layer. This is especially hard because features tend to be more coupled when existing in the same context.
It becomes harder to get an accurate overview of what the feature does (cognitive overload). Thereby also making it harder to refactor later.

A different approach is to use the features as the primary folders in a vertical slicing of the architecture. This could be done in the following way:

src
- feature1
  - application
  - domain
  - web-client
- feature2
  - application
  - domain
  - web-client

Here feature1 and feature2 are at the top folder and the layers are inside the features. It is trivial to see that removing a single feature is simpler. Additionally it becomes easier to add new features as the requirements for doing so are more obvious by being placed in the same folder.

If you have more technical features like logging or authentication they could also more easily be incorporated into this structure as they might not need all architectural layers. For example:

src
- feature1
  - application
  - domain
  - web-client
- feature2
  - application
  - domain
  - web-client
- logging
  - application
- authentication
  - web-client

This versatility makes a feature oriented structure more resilient and maintainable in a production project.