Структуры на основе фич работают в большинстве случаев лучше, чем технические слои, особенно в больших проектах. Причина простая: когда ты обращаешься к фиче, все релевантные файлы находятся в одном месте, а не разбросаны по разным папкам "components" и "services". Вместо того чтобы иметь `/src/components/UserCard`, `/src/services/userService`, `/src/utils/userHelpers`, ты складываешь всё вместе в `/src/features/user/`. Это упрощает ориентацию и снижает когнитивную нагрузку при кодировании. Особенно когда над проектом работает несколько человек - меньше конфликтов и путаницы с вопросом "куда это вообще должно идти?".
Внутри своих фич ты можешь построить консистентную внутреннюю структуру. Что-то вроде `/features/user/components`, `/features/user/hooks`, `/features/user/types`, `/features/user/utils` имеет смысл - здесь есть ясные подкатегории, но всё тематически связано. Для действительно больших модулей имеет смысл ещё одна иерархия по подфичам. Практический пример: твой `/features/user` можно разделить на `/features/user/authentication`, `/features/user/profile`, `/features/user/settings`.
Всё то, что охватывает несколько фич - общие утилиты, глобальные типы, центральные сервисы - ты кладёшь в отдельные папки вроде `/shared`, `/lib` или `/core`. Это действительно исключение, а не правило. Главное - выбрать структуру и последовательно её придерживаться. Что работает лучше всего, зависит и от размера, и от стека твоего проекта, но Feature-First в наши дни практически является стандартом.