Архитектура Flutter проекта простым языком. Clean Arch (MVVM, DI, Bloc, Inversion of Control)

Для чего нужна архитектура?

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

Clean Architecture

Clean Architecture является одной из самых популярных архитектур в мире разработки программного обеспечения, особенно для крупных и средних проектов. Она разработана Робертом Мартином (Uncle Bob) и получила широкое распространение благодаря своей модульности, гибкости и легкости в сопровождении.

Почему же она завоевала такую популярность и симпатию среди Flutter разработчиков и не только? Вот несколько причин, почему эта архитектура столь популярна и эффективна:

Четкое разделение ответственности на слои:

• Презентационный слой (Presentation): Отвечает за пользовательский интерфейс и взаимодействие с пользователем. Здесь находятся виджеты Flutter, которые отображают данные и обрабатывают пользовательские действия. Кроме интерфейса в текущем слое находится наш менеджер состояния и view модель.

• Слой домена (Domain): Содержит бизнес-логику и правила приложения. Это сердцевина нашей фичи или приложения, которая независима от фреймворков и внешних библиотек.

• Слой данных (Data): Отвечает за управление данными, включая работу с базами данных, сетевыми запросами и кешированием.

Позже мы разберем где и какие именно папки, классы и их реализации должны находится.

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

MVVM - Model View View Model - это архитектурный паттерн, который используется для разделения логики представления (UI) и бизнес-логики в приложениях, стоит использовать только в том случае если в нашем виджете , который должен быть максимально “глупым”, существует зависимости от репозитория или же методов. Если присутствует большое количество переменных, переопределенных методов по типу initState так же нужно создать viewModel, в которую мы перенесем всю ненужную "глупому" виджету логику. Ниже нарисованная схема поможет лучше понять смысл этого паттерна.

Inversion of Control (инверсия управления) - это некий абстрактный принцип, набор рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент системы должен быть как можно более изолированным от других, не полагаясь в своей работе на детали конкретной реализации других компонентов.

Dependency Injection (внедрение зависимостей) - это одна из реализаций этого принципа помимо этого есть еще: Service Locator - широко известный анти-шаблон. А чем он занимается? Предоставляет доступ одних объектов к другим объектам.

Принципы ViewModel

В каждом проекте вы неизбежно столкнетесь с использованием ViewModel. Понимание этой концепции часто вызывает затруднения у начинающих разработчиков. Поэтому не будет лишним её разобрать.

Model - Модель представляет данные и бизнес-логику приложения. Она отвечает за управление данными и обеспечение согласованности и целостности приложения. В нашем случае Model будет абстрактным репозиторием из Domain слоя.
View - View отвечает за представление данных пользователю и захват пользовательских взаимодействий. Это пользовательский интерфейс, с которым взаимодействуют пользователи. Сохраняйте виджеты максимально «глупыми», минимизируя логику в компонентах пользовательского интерфейса вынося их в ViewModel.
ViewModel - это посредник между Model и View. Он содержит логику представления, раскрывая данные и команды, к которым View может привязываться. ViewModel разработан для тестирования независимо от UI. Он также часто инкапсулирует состояние View и обрабатывает ввод и взаимодействие пользователя.

Пример ViewModel:

class MapViewModel {
  MapViewModel({required this.context,required this.infoLocationRepository,required this.locationRepository});
  final BuildContext context;
  final LocationRepository locationRepository;
  final InfoLocationRepository infoLocationRepository;
  
  late final UserLocationBloc locationBloc = UserLocationBloc(repository: locationRepository);
  late final UserInfoLocationBloc userInfoLocationBloc = UserInfoLocationBloc(infoLocationRepository: infoLocationRepository);
  late GoogleMapController mapController;
  
  ValueNotifier selectLat = ValueNotifier([double]);
  ValueNotifier selectLng = ValueNotifier([double]);
  String styleMap = '';
  get onMapCreated => _onMapCreated;
  get initialize => _initialize;

  void _onMapCreated(GoogleMapController controller) {
    mapController = controller;
  }

  void _initialize() {
    locationBloc.add(GetStartUserLocation());
    DefaultAssetBundle.of(context).loadString('style.json').then((onValue) {
      styleMap = onValue;
    });
  }
}

Теперь наш виджет по настоящему "глупый", в нем нет реализации методов и прочего, теперь это все в нашей view model.

Структура проекта:

Utils

Utils содержит в себе все настройки и коллекции приложения. Тема, цвета нашего приложения. Коллекции с нашими svg/png картинками. Какая-то часть разработчиков называют данную папку theme.

Features

Features папка будет содержать все функции приложения, такие как аутентификация, профиль… А уже каждая фича будет разделяться на слои:

Data Layer

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

• Repositories - Здесь хранится вся реализация бизнес логики, которая имплементируется от абстрактных классов описанных в Domain.

• Models - Модельки наших ответов с сервера.

• Service - Тут хранится реализация логики обращения к API или же к БД. В моем случае я использую библиотеку Retrofit, которая не нуждается в обработке и долгой реализации, именно поэтому наш абстрактный класс будет реализован сразу в Data. Как вы видите благодаря многим инструментам мы можем отойти от строгости структурирования чистой архитектуры.

Domain Layer

Domain Layer, также известный как Business Logic или Use Case Layer, содержит основные бизнес-правила и логику приложения. Он представляет собой сердце программной системы, инкапсулируя существенную функциональность, которая не зависит от какой-либо конкретной структуры.

• Repositories - Здесь мы объявляем наши абстрактные классы, которые реализованы в data.

• Entity - наши сущности, отличаются от моделей тем, что модельки используются для того, чтобы распарсить данные, а сущности для того чтобы использовать их.

• Use_case - часто реализуются в виде отдельных классов или методов, которые инкапсулируют бизнес-логику. Это позволяет отделить бизнес-логику от деталей реализации (интерфейсы пользователя, базы данных и т.д.) и сделать код более модульным и тестируемым.

Presentation Layer

Presentation Layer (слой представления) в программировании — это слой архитектуры приложения, который отвечает за отображение данных пользователю и обработку взаимодействий пользователя с приложением. Он играет важную роль в том, как пользователи взаимодействуют с приложением и как данные и команды передаются между пользователем и бизнес-логикой.

• Bloc - У вас эта папка может называться по другому , все зависит от вашего стейт-менеджера, у меня это блок.

• Page - здесь хранятся наша верстка.

• View Model - Здесь находится модель наших экранов

• Widget - Виджеты которые дают верстке не читабельный вид и требуют вынесения в отдельные файлы (например из-за своей громоздкости).

Core

Папка core представляет собой фундаментальный модуль, содержащий ключевые компоненты, такие как утилиты, маршруты, сеть, службы, валидаторы и т. д. Часть разработчиков кучу папок суют в core, а кто-то разделяет как и features на слои: domain, data, presentation; как это делаю я и большинство разработчиков. Так легче ориентироваться и находить нужные тебе файлы.

Data:

• Storage - Описание работы с нашим хранилищем.

• Translation - наша логика перевода.

Domain:

• Di - di container в котором мы проинициализируем зависимости приложения (классы которые должны быть single ton).

• Repository - здесь хранится вся логика наших шаблонов применяемых к большому количеству реализаций. Например Dio Interceptor - настраивает все запросы (В моем случае добавляет в хедеры токен, который используется во всех запросах) или ответы. (У меня при ответе сервера 401 ошибки выполняется перезаписывание токена и повторное обращение к серверу)

• Router - тут находятся наши пути, по которым мы будем перемещаться между экранами.

• Use_case - тот же шаблон как и repository но применяемый не для самой реализации, а для обработки существующей реализации. Например шаблон ответа от сервера:

sealed class Result<T> {
  bool get isSuccess;

  const factory Result.data(T data) = DataResult;

  const factory Result.error(List<String> errorList) = ErrorResult;
}

class DataResult<T> implements Result<T> {
  final T data;

  const DataResult(this.data);

  @override
  bool get isSuccess => true;
}

class VoidResult<T> implements DataResult<T?> {
  @override
  bool get isSuccess => true;

  @override
  final T? data;

  const VoidResult([this.data]);
}

class ErrorResult<T> implements Result<T> {
  final List<String> errorList;

  const ErrorResult(this.errorList);

  @override
  bool get isSuccess => false;
}

То есть мы обрабатываем уже ответ от существующей реализации.

Presentation:

• Page - тут находятся наши базовые скрины, такие как BottomNavigation. Которые управляют навигацией всего приложения.

• Widget - тут все, часто переиспользуемые виджеты.

У чистой архитектуры нет строгих принципов. Это лишь базовые папки и подходы, которые были описаны в этой статье. В каждой компании свои подходы, но познакомившись с той структурой, что описал я, не будет никаких проблем разобраться в каком либо уже существующем проекте. Я вам гарантирую, что в core/domain не будут только те папки, сказаны мною выше. Там может находится логика обработки push уведомлений, логика входа с помощью отпечатка пальца и так далее. Каждый проект несет за собой свои особенности и фичи.

Но если вам скажут создать новый функционал, например реализовать передачу местоположения пользователя в фоном режиме, вы уже знаете что это будет описано по пути core/domain/repository и core/data/repository. В core потому это не является какой-то фичей приложения, у нее нет ui, она работает в любом месте, в любых условиях. В domain потому что у нас выполняется логика - достать место положение. Нам придется создать абстрактный класс:

abstract class Location {
	Location getLocation();
}

Далее в папке core/data/repository- мы уже выполняем его реализацию

class LocationImpl implements Location {
	@override
	Location getLocation(){
		//code
	};
}

Надеюсь, эта статья была для вас полезна, желаю вам удачи 😃