Начните с предметно-ориентированного проектирования в своих кодовых базах Flutter.

Это пример настройки доменно-ориентированного дизайна для Flutter. Я использую скелетное приложение Flutter, чтобы все было просто. Давай начнем.

Основной или доменно-ориентированный дизайн

Основной концепцией предметно-ориентированного проектирования является использование объектов-значений в качестве атомарных единиц для связи с компонентами и слоями. На этот раз мы создаем очень простой объект-значение:

Вы заметите, что мы помечаем его как неизменяемый и что он использует миксин Equatable. И поэтому, когда мы используем this в качестве базового класса, он также имеет тенденцию быть объектом-значением:

Во-первых, давайте реализуем это:

Теперь давайте расширим его до Model:

И затем реализация SampleItemModel:

А теперь давайте посмотрим, как мы это тестируем:

Я использую mocktail для макетов, но mockito также имеет тот же базовый API, вот макеты:

И макет Model:

И тогда тест будет:

Теперь помните, что это каркасное приложение, в котором есть только модель списка и нет пользовательского ввода.

Также нет никакой логики для доступа к какому-либо нелокальному API. Таким образом, осталось добавить один источник данных, одноразовый вариант использования и модель представления списка. Итак, добавим это.

Завершение примера

Начнем с реализации модели представления списка:

И модульный тест будет таким:

И теперь нам нужен источник данных для этой модели представления списка:

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

Теперь позвольте мне немного поговорить об ошибках и исключениях. Теперь позвольте мне спросить, почему я не использую здесь исключение? Две ключевые причины.

Во-первых, каждый раз, когда возникает ошибка, он дает трассировку стека.

Во-вторых, очевидно, что мы сопоставляем наш уровень предметной области, чтобы не создавать исключения для остановки приложения. Таким образом, мне нужно использовать класс Error, а не класс исключений:

Итак, модульный тест для источника данных:

Макет:

И модульный тест:

И, наконец, у нас есть вариант использования:

Интерфейс:

И конкретная реализация:

И модульный тест:

Дополнительно

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

Я сохранил простоту и не стал добавлять другие части DDD, а именно остальную часть механизма объекта-значения и диспетчеризацию событий.

Другой механизм объекта ценности связан с изменением сущностей на ValueObject(Types) и настройкой валидаторов и других интеграций. Затем расширяем это до объектов Event State Value и создаем диспетчеры событий для варианта использования, источника данных, репозитория и модели представления.

Короче проводка управления состоянием. Напротив, в Clean Arch во Flutter, как правило, просто подключают модель представления для управления состоянием с помощью BLoC или Redux.

Заключение

Это некое ядро ​​доменно-ориентированного дизайна, с которого можно начать. Далее следует создание более сложных объектов-значений и диспетчеризация событий. Пример кода можно найти в этом репозитории:



GitHub — fredgrott/equatable_ddd_modeling: демонстрационный проект Flutter с использованием equatable и ddd
Демонстрационный проект Flutter, показывающий, как использовать объекты значений Equatable в качестве связующего звена между интерфейсами и реализацией в…github.com



Вот некоторые из плагинов сообщества Flutter, над созданием которых я работаю:

Want to Connect?
Follow me on Twitter. You can also stay updated with my latest Flutter sprints available in this GitHub Repository.

Ресурсы

Некоторые полезные ресурсы (ссылки на книги относятся к архивам бесплатных pdf-файлов и выдаче книг):