На какие слои будешь разделять приложения при разработке с нуля?

Архитектурные слои iOS-приложения

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

1. Слой представления (Presentation Layer)

Этот слой отвечает за отображение данных пользователю и обработку его действий. Здесь используются паттерны MVVM, MVP или VIPER, чтобы отделить логику от UI.

• Компоненты:

    - **ViewControllers** и **UIViews** (или SwiftUI Views) — отвечают только за отрисовку.
    - **ViewModels** (или Presenters) — содержат бизнес-логику для отображения, преобразуют данные из доменного слоя в формат, удобный для UI.
    - **Координаторы (Coordinators)** или **Роутеры** — управляют навигацией, изолируя её от ViewControllers.

// Пример ViewModel в MVVM
final class ProductListViewModel {
    @Published private(set) var products: [ProductDisplayModel] = []
    private let fetchProductsUseCase: FetchProductsUseCaseProtocol
    
    func loadProducts() {
        fetchProductsUseCase.execute { [weak self] result in
            switch result {
            case .success(let domainProducts):
                self?.products = domainProducts.map { ProductDisplayModel(from: $0) }
            case .failure(let error):
                // Обработка ошибки для UI
            }
        }
    }
}

2. Слой бизнес-логики (Domain Layer)

Ядро приложения, полностью независимое от фреймворков и внешних зависимостей. Содержит сущности (Entities) и сценарии использования (Use Cases).

• Сущности — модели данных, отражающие ключевые понятия предметной области (например, User, Order). Они не должны содержать аннотаций Codable или зависимостей от базы данных.
• Сценарии использования (Use Cases / Interactors) — инкапсулируют конкретные бизнес-правила. Каждый Use Case отвечает за одну операцию (например, AuthenticateUserUseCase).

// Пример Use Case
protocol FetchProductsUseCaseProtocol {
    func execute(completion: @escaping (Result<[Product], Error>) -> Void)
}

final class FetchProductsUseCase: FetchProductsUseCaseProtocol {
    private let repository: ProductRepositoryProtocol
    
    func execute(completion: @escaping (Result<[Product], Error>) -> Void) {
        repository.fetchProducts(completion: completion)
    }
}

3. Слой данных (Data Layer)

Отвечает за получение и хранение данных, реализуя интерфейсы, определённые в доменном слое. Состоит из:

• Репозитории (Repositories) — абстракции над источниками данных. Предоставляют доменному слою единый API, скрывая детали реализации (сеть, база данных, кэш).
• Data Sources — конкретные реализации работы с данными: NetworkService для API, CoreDataManager для базы данных, UserDefaults для настроек.
• Data Transfer Objects (DTOs) — модели для парсинга сетевых ответов или работы с БД, которые затем преобразуются в доменные сущности.

// Пример Repository
protocol ProductRepositoryProtocol {
    func fetchProducts(completion: @escaping (Result<[Product], Error>) -> Void)
}

final class ProductRepository: ProductRepositoryProtocol {
    private let networkService: NetworkServiceProtocol
    private let cache: ProductCacheProtocol
    
    func fetchProducts(completion: @escaping (Result<[Product], Error>) -> Void) {
        // Сначала проверяем кэш, затем сеть
        if let cached = cache.loadProducts() {
            completion(.success(cached))
            return
        }
        
        networkService.fetchProducts { [weak self] result in
            switch result {
            case .success(let dtos):
                let domainProducts = dtos.map { $0.toDomain() }
                self?.cache.saveProducts(domainProducts)
                completion(.success(domainProducts))
            case .failure(let error):
                completion(.failure(error))
            }
        }
    }
}

4. Слой инфраструктуры (Infrastructure Layer)

Вспомогательные сервисы и утилиты, которые используются несколькими слоями:

• Сетевой слой (например, на основе URLSession или Alamofire) с обработкой ошибок, логированием запросов.
• Локализация, аналитика (Analytics), кейчейн (Keychain), менеджер зависимостей (Dependency Injection Container).
• Сторонние библиотеки — их следует инкапсулировать в адаптеры, чтобы минимизировать связанность.

Ключевые принципы разделения:

1. Зависимости направлены внутрь (Dependency Rule): внешние слои зависят от внутренних, но не наоборот. Domain Layer не знает о существовании Data или Presentation слоёв.
2. Инверсия зависимостей (Dependency Inversion): слои общаются через абстракции (протоколы), а не конкретные реализации.
3. Тестируемость: Domain Layer тестируется юнит-тестами без моков фреймворков, Data Layer — с интеграционными тестами, Presentation Layer — с UI-тестами или snapshot-тестированием.

Такое разделение позволяет легко заменять компоненты (например, перейти с REST на GraphQL или заменить UIKit на SwiftUI), повторно использовать код (особенно Domain Layer) и эффективно распределять работу в команде.