Стандартная структура (по типам файлов)
lib/
├── models/
├── services/
├── widgets/
├── screens/
├── utils/
└── main.dart
Плюсы:
▫️Простота понимания
▫️Быстрый старт для небольших проектов
Минусы:
▫️Может превратиться в беспорядок, если проект большой
▫️Сложнее находить связанные файлы
Функциональная структура (по фичам)
lib/
├── feature_a/
│ ├── models/
│ ├── widgets/
│ ├── screens/
│ └── bloc/
├── feature_b/
│ ├── models/
│ ├── widgets/
│ ├── screens/
│ └── bloc/
├── core/
│ ├── app/
│ ├── constants/
│ ├── services/
│ └── utils/
└── main.dart
Плюсы:
▫️Лучшая масштабируемость
▫️Четкое разделение ответственности
▫️Удобство для командной работы
Минусы:
▫️Сложнее для новичков
▫️Избыточность для маленьких проектов
Гибридная структура
Сочетает оба подхода: начинаете с типа файлов и переходите к фичам по мере роста проекта.
Что входит в директории?
Core-директория содержит общие элементы приложения:
▫️app — основная конфигурация приложения
▫️constants — константы, стили, строки
▫️services — API, хранилища, сервисы
▫️utils — вспомогательные функции, extensions
▫️routes — маршрутизация
Feature-директории содержат:
▫️data — модели, DTO, репозитории
▫️domain — бизнес-логика (BLoC, Cubit, Provider)
presentation - UI (виджеты, страницы)
▫️feature.dart — экспорт всех файлов фичи
Что стоит делать?
⚡️Используйте barrel-файлы (feature.dart) для упрощения импортов.
// В папке feature_a/feature_a.dart
export 'models/model_a.dart';
export 'widgets/widget_a.dart';
export 'screens/screen_a.dart';
⚡️Следуйте соглашениям об именовании. В разных командах могут быть свои правила, я покажу на примере, как это заведено у нас:
*_screen.dart для полноценных страниц
*_model.dart для моделей данных
*_event.dart, *_state.dart для BLoC
⚡️Избегайте глубокой вложенности — старайтесь не превышать 3-4 уровня.
⚡️Разделяйте по ответственности, а не по типам, когда проект растет.
Выбор структуры зависит от размера и сложности вашего проекта. Начинайте с простого и рефакторите по мере роста приложения. Главное — соблюдать консистентность и следить, чтобы структура оставалась понятной для всех разработчиков в команде.
А какой подход используете вы?