Следуя чистой архитектуре, описанной дядей Бобом, весь ваш код, содержащий бизнес-логику (правила) (домена), должен находиться внутри бизнес-уровня.
Например, мы разрабатываем мобильное приложение для онлайн-заказа еды / одежды. Не имеет значения.
Уровень презентации: (состоит из представления и докладчика)
- Докладчик - обрабатывать намерения просмотра (нажатие кнопок, отображение визуализации и т. д.), вызывать бизнес-интеракторы после получения результата от интеракторов, говорит, чтобы просмотреть, чтобы отобразить текущее состояние экрана / макета.
- Просмотр - ничего, кроме визуализации пользовательского интерфейса, сохраняйте представление глупым, вся ваша логика представления должна быть в презентаторе.
Пример случая: На этом уровне вы можете проверить, например: экран корзины, выбранный пользователем, ваш уровень представления делает запрос к интерактору, который возвращает элементы корзины. Если список пуст, в представлении отображается макет с заголовком. Карточка пуста, в противном случае отображается список элементов.
Уровень бизнеса / домена: (состоит из интерактора, вспомогательных классов и т. д.)
Правило номер один - сохранить свой домен слой чистый. Если вы используете gradle, вы можете использовать многомодули с пустыми зависимостями. Только язык, rxjava, потому что это почти стандарт нашего времени.
Пример: Вам необходимо проверить информацию о заказе пользователя (адрес доставки, начальный). Вся ваша логика должна быть здесь. Проверка длины, проверка регулярного выражения и т. Д.
Уровень данных:
Умеет сохранять, извлекать, обновлять и удалять информацию. Все о настойчивости. В случаях с Android: уровень данных может делать http-запрос через retrofit2, room orm и т. Д. Кеш начинается здесь.
Если ваше приложение не содержит большого количества бизнес-правил, вы можете избежать бизнес-уровня. Это зависит от проекта.
Также важно использовать принципы SOLID. Это сделает вашу архитектуру понятной, гибкой и удобной в обслуживании. Дополнительную информацию см. здесь.
21.12.2018
