Для чего нужен Domain layer?

Назначение Domain Layer (Слоя предметной области)

Domain Layer (слой предметной области, доменный слой) — это ключевой архитектурный слой в современных Android-приложениях, следующих принципам чистой архитектуры (Clean Architecture) или многослойной архитектуры (например, MVVM с репозиториями). Его основное предназначение — инкапсулировать бизнес-логику приложения, делая её независимой от фреймворков, внешних библиотек, UI и инфраструктурных деталей (таких как базы данных или сетевые API).

Ключевые цели и преимущества

1. Изоляция бизнес-логики: Доменный слой содержит самую ценную часть приложения — правила, по которым оно работает. Вынося их в отдельный слой, мы защищаем логику от изменений во внешних слоях (например, смены библиотеки для работы с сетью или переделки экранов).

2. Повышение тестируемости: Поскольку доменная логика не зависит от Android SDK, Context, Activity или фреймворков для БД, её можно тестировать с помощью быстрых и изолированных юнит-тестов на JVM, без необходимости запуска эмулятора или устройства.

3. Упрощение поддержки и читаемости кода: Логика приложения сосредоточена в одном месте по определённым правилам. Новому разработчику проще понять, как работает приложение, изучая доменный слой, без необходимости разбираться в деталях реализации UI или данных.

4. Поддержка принципа единственной ответственности (SRP): Каждый компонент доменного слоя (UseCase, Interactor, Domain Model) отвечает за чётко ограниченную бизнес-операцию или правило.

Основные компоненты Domain Layer

Обычно доменный слой включает:

• Сущности (Entities) / Модели предметной области (Domain Models): Классы, отражающие ключевые концепции предметной области (например, User, Order, Product). Это чистые классы данных (Kotlin data class) без аннотаций фреймворков (в отличие от моделей данных Data Layer).
• Сценарии использования (Use Cases / Interactors): Классы, которые инкапсулируют одну конкретную бизнес-операцию. Каждый UseCase должен делать что-то одно (например, GetUserProfileUseCase, ValidatePaymentUseCase). Они координируют поток данных между репозиториями и преобразуют модели данных в доменные модели.
• Репозитории (Интерфейсы) (Repository Interfaces): Абстракции (интерфейсы), определяющие контракты того, какие данные нужны бизнес-логике. Их реализация находится в Data Layer. Это обеспечивает инверсию зависимостей (Dependency Inversion Principle - DIP).

Пример реализации на Kotlin

Рассмотрим фрагмент доменного слоя для приложения управления задачами.

// 1. Domain Model (Сущность)
data class Task(
    val id: String,
    val title: String,
    val description: String,
    val isCompleted: Boolean,
    val dueDate: LocalDate?,
    val priority: Priority // enum class Priority { LOW, MEDIUM, HIGH }
)

// 2. Repository Interface (Контракт)
interface TaskRepository {
    suspend fun getTasks(): List<Task>
    suspend fun getTaskById(id: String): Task?
    suspend fun saveTask(task: Task)
    suspend fun deleteTask(id: String)
}

// 3. Use Case (Сценарий использования)
class GetActiveHighPriorityTasksUseCase(
    private val taskRepository: TaskRepository // Зависимость от абстракции!
) {
    suspend operator fun invoke(): List<Task> {
        val allTasks = taskRepository.getTasks()
        // Вся бизнес-логика фильтрации сосредоточена здесь.
        return allTasks.filter { task ->
            !task.isCompleted && task.priority == Priority.HIGH
        }.sortedBy { it.dueDate } // Дополнительное бизнес-правило сортировки
    }
}

Взаимодействие с другими слоями

• Data Layer → Domain Layer: Слой данных зависит от доменного слоя, так как реализует его интерфейсы репозиториев. Он преобразует модели из сетевых или БД-форматов (NetworkTask, RoomTask) в доменные модели (Task).
• Presentation Layer → Domain Layer: Слой презентации (ViewModel, Presenter) использует UseCases для выполнения бизнес-операций. Он получает доменные модели и преобразует их в UiState для отображения.

Итог: Внедрение Domain Layer — это инвестиция в долгосрочную поддерживаемость и надёжность кода. Он превращает приложение из набора экранов, напрямую работающих с сетью и БД, в систему с чётко выраженной и легко тестируемой бизнес-логикой в центре. Это особенно критично для сложных, долгоживущих проектов с частыми изменениями требований.