Как может быть организовано получение данных из сети с использованием принципов Clean Architecture?

Clean Architecture помогает отделить сетевую реализацию от бизнес-логики и UI.

1. Presentation вызывает Use Case

Например, ViewModel вызывает:

val result = getUserUseCase(id)

ViewModel не знает:

• какой HTTP-клиент используется

• где находится API

• как устроены DTO

Она работает только с доменными моделями.

2. Use Case обращается к репозиторию

Use case реализует бизнес-логику:

• определяет сценарии загрузки

• выбирает, что делать при ошибках

• работает с доменными сущностями

Пример:

class GetUserUseCase(private val repo: UserRepository) {
    suspend operator fun invoke(id: String) = repo.getUser(id)
}

3. Репозиторий использует Data Sources

Репозиторий — единственная точка, которая знает о реальных источниках данных:

• RemoteDataSource делает HTTP-запросы

• LocalDataSource читает/пишет в базу

• Repository решает, как объединять данные

Например:

• сначала проверить кэш

• затем запросить API

• сохранить в базу

4. RemoteDataSource выполняет сетевой запрос

Обычно это Retrofit/Ktor:

interface ApiService {
    @GET("user/{id}")
    suspend fun getUser(@Path("id") id: String): UserDto
}

DataSource получает DTO — модель, описывающую структуру ответа сервера.

5. Преобразование DTO → Domain

Репозиторий преобразует ответ сервера:

fun UserDto.toDomain() = User(name, age)

Это защищает доменную модель от изменений API.

6. Возврат ответа наверх

Путь данных выглядит так:

Network → DTO → Repository → Domain Model → Use Case → ViewModel → UI

Вывод

Clean Architecture изолирует сетевой слой, обеспечивая гибкость, тестируемость и устойчивость к изменениям API. Каждый слой выполняет строго определённую роль и не знает о деталях соседних слоёв.