Да, есть.
При разработке на чистой архитектуре использовал следующие слои:
- Domain Layer: Содержит бизнес-логику и сущности. Он не зависит от других слоев. Определяются Use Cases (интеракторы) и репозитории-интерфейсы.
- Data Layer: Реализует интерфейсы репозиториев из Data Layer. Включает работу с данными (сети, базы данных, SharedPreferences). Часто используются репозитории для преобразования данных из внешних источников в доменные сущности.
- Presentation Layer: Содержит View (Fragment, Activity) и Presenter/ViewModel. Отвечает за отображение данных и взаимодействие с пользователем. Обращается к Use Cases из Domain Layer.
Зависимости между слоями:
- Presentation Layer зависит от Domain Layer.
- Data Layer зависит от Domain Layer.
Паттерны и принципы, применяемые в чистой архитектуре:
- SOLID: Особенно принцип инверсии зависимостей (Dependency Inversion Principle).
- Dependency Injection: Для упрощения тестирования и управления зависимостями (например, с использованием Dagger, Koin).
- Repository Pattern: Абстракция над источниками данных.
- Use Cases (Interactors): Представляют конкретные операции в бизнес-логике.
Пример структуры проекта:
plaintext
Взаимодействие между слоями:
- View вызывает метод ViewModel.
- ViewModel вызывает соответствующий Use Case (доменная логика).
- Use Case обращается к интерфейсам репозиториев из Domain Layer.
- Реализации репозиториев (в Data Layer) получают данные из источников (сеть, БД).
- Репозитории преобразуют данные в доменные сущности и возвращают их Use Case.
- Use Case обрабатывает данные и возвращает результат ViewModel.
- ViewModel обновляет данные, которые отображаются на View.
Использование чистой архитектуры позволяет:
- Улучшить тестируемость: Каждый слой может быть протестирован изолированно.
- Увеличить поддерживаемость: Изменения в одном слое минимально влияют на другие.
- Повысить гибкость: Проще заменять реализации источников данных или представления UI.
- Снизить связанность: Отделение бизнес-логики от деталей реализации.