Как направлены зависимости между слоями в Clean Architecture?

Clean Architecture, предложенная Робертом Мартином (Дядюшкой Бобом), структурирует приложение в виде концентрических слоёв. Ключевым правилом, обеспечивающим гибкость и тестируемость, является Правило зависимостей (Dependency Rule).

Направление зависимостей

Зависимости всегда направлены внутрь, к центру архитектуры. Это означает, что код во внутренних слоях ничего не знает о внешних слоях и не зависит от них. Напротив, внешние слои знают о внутренних и зависят от них.

Слои и их зависимости

Рассмотрим классические слои (от внутренних к внешним):

• Сущности (Entities): Самый внутренний слой, содержащий бизнес-объекты и правила. Он абсолютно независим.
• Сценарии использования (Use Cases): Содержит бизнес-правила приложения. Зависит только от слоя Сущностей.
• Адаптеры (Interface Adapters): Преобразует данные между форматами, удобными для Use Cases и внешними системами (например, GUI, базами данных). Зависит от Use Cases и Entities.
• Фреймворки и Драйверы (Frameworks & Drivers): Внешний слой с UI, базами данных, веб-фреймворками. Зависит от внутренних слоёв.

Как это работает на практике

Чтобы внешний слой (например, контроллер веб-фреймворка) мог использовать внутренний слой (Use Case), применяется инверсия зависимостей (Dependency Inversion Principle). Внешний слой определяет интерфейс (например, репозитория), который ему нужен. Этот интерфейс принадлежит внутреннему слою (Use Cases). Реализация интерфейса (например, конкретный репозиторий для MongoDB) находится во внешнем слое и зависит от этого интерфейса.

Пример кода

Рассмотрим фрагмент, иллюстрирующий правило. Сначала определим интерфейс репозитория во внутреннем слое (Use Cases):

// Внутренний слой (Use Cases)
// Интерфейс объявлен здесь, от него зависит Use Case.
export interface UserRepository {
    findById(id: string): Promise;
}

// Use Case зависит только от интерфейса.
export class GetUserUseCase {
    constructor(private userRepository: UserRepository) {}
    async execute(userId: string): Promise {
        return this.userRepository.findById(userId);
    }
}

Теперь реализация во внешнем слое (Infrastructure):

// Внешний слой (Infrastructure/Adapters)
// Конкретная реализация зависит от интерфейса из внутреннего слоя.
import { UserRepository } from '../core/usecases';
import { UserModel } from './mongoose/models';

export class MongoUserRepository implements UserRepository {
    async findById(id: string): Promise {
        const userDoc = await UserModel.findById(id);
        // ... преобразование документа в сущность User
        return mappedUser;
    }
}

В точке сборки приложения (например, в main-файле) зависимость инжектируется: экземпляр MongoUserRepository передаётся в GetUserUseCase. Таким образом, поток зависимостей во время компиляции направлен внутрь (Use Case зависит от интерфейса Repo), а поток управления во время выполнения направлен наружу (Use Case вызывает реализацию из внешнего слоя).

Вывод

Направление зависимостей внутрь — это фундаментальное правило Clean Architecture, которое изолирует бизнес-логику от внешних изменений. Это делает систему более устойчивой к замене фреймворков, баз данных или UI, и значительно упрощает модульное тестирование. Применяйте этот подход при разработке сложных долгоживущих приложений, где важны гибкость и поддерживаемость.