Раньше я разделял файлы проекта по техническим аспектам. На примере проекта с Редаксом это выглядит примерно так:

src
├── actions
├── api # всё общение с сервером
├── components # всё, что относится к представлению
├── config # централизованная конфигурация всех фич
├── constants
├── containers
├── reducers
├── selectors
└── utils # все вспомогательные функции

На практике такая структура оказалась для меня неудобна и немасштабируема.

Во-первых, она завязана на технические аспекты используемых библиотек (в данном случае структура завязана на Редакс), и при смене библиотеки (например, при замене Редакса на Мобикс) придётся перелопачивать всю структуру.

Во-вторых, программисты работают в первую очередь с фичами вроде авторизации или списка покупок. При такой структуре код, относящийся к одной фиче, становится разбросан по всему проекту, и программисту приходится бегать между директориями в поисках нужных файлов, а при рефакторинге и удалении кода скорее всего что-то будет теряться (если в проекте нет статической типизации).

Здравой альтернативой оказалась организация стуктуры проекта по фичам (и сущностям предметной области). На примере того же приложения с Редаксом новая структура выглядит так:

src
├── modules
│   ├── auth
│   │   ├── actions.js
│   │   ├── api.js
│   │   ├── config.js
│   │   ├── constants.js
│   │   ├── reducer.js
│   │   ├── selectors.js
│   │   └── utils/
│   └── purchases
│       ├── actions.js
│       ├── api.js
│       ├── config.js
│       ├── constants.js
│       ├── reducer.js
│       ├── selectors.js
│       └── utils/
└── view
    ├── components/
    └── pages/

При таком подходе любые технические аспекты, относящиеся к одной фиче, лежат рядом друг с другом и их не нужно искать по всему приложению. Сами фичи становятся изолированными модулями, предоставляющими наружу какой-то API, при этом детали их реализации и конкретные используемые библиотеки остаются под капотом.