От переводчика
В течении полугодя изучаю язык программирования Dart и пробую писать простые интерфейсы на его фреймворке Flutter. Но когда приложение начинает занимать больше двух экранов или получать данные по сети, то встает вопрос о его структуре.Ниже превожу перевод одной статьи по этой теме, которая мне показалась полезной. По крайней мере познакомила меня с описанными подходами.
Структура Flutter-приложения: feature-first или layer-first
Какова наилучшая структура проекта для средних / больших Flutter-приложений?
Скорее всего, нет "правильного" ответа, который подходил бы для всех проектов.
Итак, давайте рассмотрим два популярных подхода, известных как "feature-first" и "layer-first", и узнаем об их различиях.
Итак, что же нам следует выбрать?
Feature-first подход
Подход "функции внутри слоев" (сначала слой) не очень подходит для больших проектов с большим количеством функций.
Для любой заданной функции файлы, принадлежащие разным слоям, находятся далеко друг от друга, и нам приходится постоянно "перепрыгивать" между слоями.
Итак, что же нам следует выбрать?
Подход "функции внутри слоев" (сначала слой) не очень подходит для больших проектов с большим количеством функций.
Для любой заданной функции файлы, принадлежащие разным слоям, находятся далеко друг от друга, и нам приходится постоянно "перепрыгивать" между слоями.
Сперва, лучше всего рассмотреть структуру проекта применительно к архитектуре приложения.
Для справки, давайте рассмотрим эту высокоуровневую архитектуру, состоящую из четырех уровней:
‣ presentation ‣ application (опционально) ‣ domain ‣ data
Если ваше приложение достаточно сложное, у нас будет несколько функций.
И каждая фича (функция) может быть представлена группой классов, которые принадлежат к четырем слоям.
Фича — это сленг, название тех или иных признаков предмета, либо явления. Другими словами, это основная функция продукта, утратив которую пользователь расстроится и перестанет им пользоваться. (прим. переводчика)
В этом контексте у нас есть два варианта в отношении структуры проекта:
слои внутри объектов
объекты внутри слоев
Итак, что же нам следует выбрать?
Layer-first подход
Подход "фичи внутри слоев" (layer-first) не очень подходит для больших проектов с большим количеством функций.
Для любой заданной функции файлы, принадлежащие разным слоям, находятся далеко друг от друга, и нам приходится постоянно "перепрыгивать" между слоями.
Но с подходом "слои внутри фичи" (feature-first) дела обстоят намного лучше.
Для данной фичи все нужные нам файлы находятся в одной и той же папке верхнего уровня.
И мы по-прежнему получаем хорошее разделение между слоями.
На практике все не всегда просто.
В начале проекта у вас может не быть хорошего представления о модели предметной области.
И это затрудняет четкое определение различных функций (фич) и соответствующую структуру проекта.
На этом этапе у вас может возникнуть соблазн создать по одной папке для каждого экрана вашего приложения.
Но это ошибка, потому что функции (фичи) - это не экраны.
Скорее, думайте о функциях как о функциональных требованиях, которые помогают пользователю выполнить определенную задачу.
На практике я обнаружил, что изучение модели предметной области приводит к гораздо лучшему пониманию всей системы в целом.
Это помогает нам определить функции, которые нам нужны, чтобы позже мы могли "создать правильную вещь".
При таком подходе вы будете лучше подготовлены к тому, чтобы определить, какие виджеты, контроллеры, службы и репозитории относятся к каждой функции.
И в результате вы сможете лучше организовать свой проект.
Конечно, к крупным проектам предъявляются некоторые дополнительные требования (инфраструктура, производительность, организационная структура).
Эти проекты часто разделены на полностью независимые модули (пакеты), принадлежащие разным командам.
Но это отличная идея - с самого начала применять дизайн, ориентированный на предметную область.
Таким образом, в конечном итоге мы получим четкие границы между различными слоями и компонентами нашего приложения, что упростит управление зависимостями в дальнейшем.
