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