Почему не стоит использовать Repository напрямую в Clean Architecture?

Почему Repository не должен использоваться напрямую в Clean Architecture

В Clean Architecture существует четкое разделение на слои: Domain (бизнес-логика), Data (доступ к данным) и Presentation (UI). Слой Domain должен оставаться независимым от деталей реализации. Repository является интерфейсом, абстрагирующим доступ к данным (базам данных, сетевым API, файловой системе), и его прямое использование нарушает ключевые принципы архитектуры.

Основные причины

1. Нарушение принципа Dependency Rule

В Clean Architecture зависимости должны направляться внутрь, к слою Domain. Слой Domain не должен зависеть от внешних слоев (например, Data). Repository, как часть слоя Data, предоставляет интерфейс для Domain, но его реализация находится в Data слое. Если Domain напрямую использует конкретный класс Repository, это создает обратную зависимость, нарушая Dependency Rule.

2. Смешение ответственности слоев

Прямое использование Repository в слое Domain приводит к смешению логики:

• Domain должен содержать чистую бизнес-логику (Use Cases, Entities).
• Data ответственен за получение, хранение и преобразование данных. При прямом использовании Repository, Domain начинает управлять деталями данных (например, выбором источника), что противоречит его назначению.

3. Сложность тестирования и нарушение инверсии зависимостей

Domain должен быть легко тестируемым без зависимости от внешних систем. Прямое использование Repository делает тесты зависимыми от его реализации (например, от реальной базы данных). Вместо этого следует применять инверсию зависимостей через интерфейсы Repository, чтобы Domain зависел только от абстракций.

// Пример правильного подхода с интерфейсом в Domain слое
interface UserRepository {
    fun getUserById(id: String): User
}

// UseCase в Domain слое использует только интерфейс
class GetUserUseCase(private val repository: UserRepository) {
    fun execute(id: String): User {
        return repository.getUserById(id)
    }
}

// Реализация интерфейса в Data слое
class UserRepositoryImpl : UserRepository {
    override fun getUserById(id: String): User {
        // Здесь реализация с доступом к базе данных или API
    }
}

4. Уменьшение гибкости и поддерживаемости

Если бизнес-логика напрямую зависит от конкретного Repository, изменения в источнике данных (например, переход с SQLite на Room или с REST API на GraphQL) потребуют изменений в Domain слое. Это нарушает принцип заменяемости и увеличивает стоимость поддержки.

Правильный подход: использование Use Cases (Interactors)

В Clean Architecture связь между слоями осуществляется через Use Cases (или Interactors):

• Use Case находится в Domain слое и реализует конкретную бизнес-операцию.
• Он получает Repository через интерфейс (внедрение зависимости) и использует его абстракцию.
• Все детали данных остаются в Data слое.

// Domain слой определяет интерфейс и Use Case
interface ProductRepository {
    fun getProducts(): List<Product>
}

class FetchProductsUseCase(private val repository: ProductRepository) {
    fun execute(): List<Product> {
        val products = repository.getProducts()
        // Бизнес-логика: фильтрация или преобразование данных
        return products.filter { it.isAvailable }
    }
}

// Data слой реализует интерфейс
class ProductRepositoryImpl(
    private val apiService: ApiService,
    private val database: ProductDatabase
) : ProductRepository {
    override fun getProducts(): List<Product> {
        // Комплексная логика: выбор источника данных (например, сначала из сети, потом из базы)
        return fetchFromNetworkOrCache()
    }
}

Практические рекомендации

1. Определяйте интерфейсы Repository в Domain слое – это гарантирует, что Domain зависит только от абстракций.
2. Инвертируйте зависимости через DI (Dependency Injection) – внедряйте реализации Repository из Data слоя в Use Cases.
3. Разделите ответственность – Domain управляет бизнес-правилами, Data управляет источниками данных.
4. Избегайте прямых вызовов Repository в UI или других внешних слоях – все операции должны проходить через Use Cases для централизации логики.

Заключение: Прямое использование Repository нарушает принципы Clean Architecture, снижает тестируемость, гибкость и поддерживаемость системы. Правильный подход – абстрагирование через интерфейсы и использование Use Cases как посредников между Domain и Data слоями, что сохраняет чистоту бизнес-логики и обеспечивает долгосрочную стабильность архитектуры.