От переводчика

В течении полугодя изучаю язык программирования Dart и пробую писать простые интерфейсы на его фреймворке Flutter. Но когда приложение начинает занимать больше двух экранов или получать данные по сети, то встает вопрос о его структуре.Ниже превожу перевод одной статьи по этой теме, которая мне показалась полезной. По крайней мере познакомила меня с описанными подходами.

Структура Flutter-приложения: feature-first или layer-first

Какова наилучшая структура проекта для средних / больших Flutter-приложений?

Скорее всего, нет "правильного" ответа, который подходил бы для всех проектов.

Итак, давайте рассмотрим два популярных подхода, известных как "feature-first" и "layer-first", и узнаем об их различиях.

Итак, что же нам следует выбрать?

Feature-first подход

Подход "функции внутри слоев" (сначала слой) не очень подходит для больших проектов с большим количеством функций.

Для любой заданной функции файлы, принадлежащие разным слоям, находятся далеко друг от друга, и нам приходится постоянно "перепрыгивать" между слоями.

Итак, что же нам следует выбрать?

Подход "функции внутри слоев" (сначала слой) не очень подходит для больших проектов с большим количеством функций.

Для любой заданной функции файлы, принадлежащие разным слоям, находятся далеко друг от друга, и нам приходится постоянно "перепрыгивать" между слоями.

Сперва, лучше всего рассмотреть структуру проекта применительно к архитектуре приложения.

Для справки, давайте рассмотрим эту высокоуровневую архитектуру, состоящую из четырех уровней:

‣ presentation ‣ application (опционально) ‣ domain ‣ data

Если ваше приложение достаточно сложное, у нас будет несколько функций.

И каждая фича (функция) может быть представлена группой классов, которые принадлежат к четырем слоям.

Фича — это сленг, название тех или иных признаков предмета, либо явления. Другими словами, это основная функция продукта, утратив которую пользователь расстроится и перестанет им пользоваться. (прим. переводчика)

В этом контексте у нас есть два варианта в отношении структуры проекта:

• слои внутри объектов

• объекты внутри слоев

Итак, что же нам следует выбрать?

Layer-first подход

Подход "фичи внутри слоев" (layer-first) не очень подходит для больших проектов с большим количеством функций.

Для любой заданной функции файлы, принадлежащие разным слоям, находятся далеко друг от друга, и нам приходится постоянно "перепрыгивать" между слоями.

Но с подходом "слои внутри фичи" (feature-first) дела обстоят намного лучше.

Для данной фичи все нужные нам файлы находятся в одной и той же папке верхнего уровня.

И мы по-прежнему получаем хорошее разделение между слоями.

На практике все не всегда просто.

В начале проекта у вас может не быть хорошего представления о модели предметной области.

И это затрудняет четкое определение различных функций (фич) и соответствующую структуру проекта.

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

Но это ошибка, потому что функции (фичи) - это не экраны.

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

На практике я обнаружил, что изучение модели предметной области приводит к гораздо лучшему пониманию всей системы в целом.

Это помогает нам определить функции, которые нам нужны, чтобы позже мы могли "создать правильную вещь".

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

И в результате вы сможете лучше организовать свой проект.

Конечно, к крупным проектам предъявляются некоторые дополнительные требования (инфраструктура, производительность, организационная структура).

Эти проекты часто разделены на полностью независимые модули (пакеты), принадлежащие разным командам.

Но это отличная идея - с самого начала применять дизайн, ориентированный на предметную область.

Таким образом, в конечном итоге мы получим четкие границы между различными слоями и компонентами нашего приложения, что упростит управление зависимостями в дальнейшем.