Что такое многослойная архитектура внутри одного приложения?

Что такое многослойная архитектура (Layered Architecture)

Многослойная архитектура (или N-Layer Architecture) — это архитектурный паттерн, который разделяет функциональность приложения на логические уровни (слои), каждый из которых выполняет строго определённую роль и взаимодействует только со смежными слоями. В контексте C# backend-приложений это фундаментальный подход к организации кода, который обеспечивает разделение ответственности (SoC), упрощает тестирование, сопровождение и развитие системы.

Основные слои типичного C# приложения

В классической многослойной архитектуре выделяют три основных слоя, хотя их количество может варьироваться:

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

    *   **Ответственность**: Взаимодействие с конечным пользователем или внешними системами (API-клиентами). В backend-контексте это чаще всего **контроллеры Web API** (ASP.NET Core) или обработчики запросов.
    *   **Задачи**: Приём HTTP-запросов, валидация входных данных (например, с помощью атрибутов `[Required]`), маршрутизация, формирование HTTP-ответов (JSON, XML). Не должен содержать бизнес-логику.

```csharp
// Пример контроллера в слое представления (ASP.NET Core Web API)
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _productService; // Зависимость от сервиса бизнес-логики

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<ProductDto>> GetProduct(int id)
    {
        var product = await _productService.GetByIdAsync(id);
        if (product == null)
            return NotFound();

        return Ok(product); // Возврат DTO, а не доменной модели
    }
}
```

2. Бизнес-слой (Business Layer) или Слой домена (Domain Layer):

    *   **Ответственность**: Содержит **ядро приложения** — бизнес-логику, правила, доменные модели и сервисы.
    *   **Задачи**: Выполнение сложных вычислений, проверка бизнес-правил, координация потока данных. Это самый важный и стабильный слой, независимый от способа представления данных или их хранения.
    *   **Ключевые концепции**: **Сущности (Entities)**, **Агрегаты (Aggregates)**, **Сервисы домена (Domain Services)**, **Спецификации (Specifications)**, **Value Objects**.

```csharp
// Пример сервиса бизнес-логики и доменной сущности
public class ProductService : IProductService
{
    private readonly IRepository<Product> _repository;

    public ProductService(IRepository<Product> repository)
    {
        _repository = repository;
    }

    public async Task<Product> GetByIdAsync(int id)
    {
        return await _repository.GetByIdAsync(id);
    }

    public async Task DecreaseStockAsync(int productId, int quantity)
    {
        var product = await _repository.GetByIdAsync(productId);
        product.DecreaseStock(quantity); // Вызов метода доменной сущности
        await _repository.UpdateAsync(product);
    }
}

// Доменная сущность (Business/ Domain Layer)
public class Product
{
    public int Id { get; private set; }
    public string Name { get; private set; }
    public int StockQuantity { get; private set; }

    // Метод, инкапсулирующий бизнес-правило
    public void DecreaseStock(int quantity)
    {
        if (quantity <= 0)
            throw new BusinessException("Количество должно быть положительным.");
        if (StockQuantity < quantity)
            throw new BusinessException("Недостаточно товара на складе.");

        StockQuantity -= quantity;
    }
}
```

3. Слой доступа к данным (Data Access Layer, DAL):

    *   **Ответственность**: Обеспечивает взаимодействие с источниками данных (БД, внешние API, файловая система). Абстрагирует верхние слои от деталей хранения.
    *   **Задачи**: Выполнение CRUD-операций, маппинг объектов БД на доменные модели, управление транзакциями.
    *   **Типичные технологии**: **Entity Framework Core**, **Dapper**, ADO.NET.

```csharp
// Пример репозитория в слое доступа к данным
public interface IRepository<T> where T : class
{
    Task<T> GetByIdAsync(int id);
    Task AddAsync(T entity);
    Task UpdateAsync(T entity);
    Task DeleteAsync(T entity);
}

public class EfCoreRepository<T> : IRepository<T> where T : class
{
    private readonly AppDbContext _context;

    public EfCoreRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task<T> GetByIdAsync(int id)
    {
        return await _context.Set<T>().FindAsync(id);
    }
    // ... остальные методы, работающие с DbContext
}
```

Дополнительные слои и концепции

• Слой модели/транспорта (DTO Layer): Часто выделяют отдельно для определения Data Transfer Objects (DTO). Это предотвращает "протекание" доменных моделей в слой представления и позволяет адаптировать данные под нужды клиента.
• Слой инфраструктуры (Infrastructure Layer): Содержит техническую реализацию, общую для нескольких проектов: логирование, отправка email, работа с кэшем, конкретные реализации репозиториев. Зависит от бизнес-слоя.
• Cross-Cutting Concerns (Сквозная функциональность): Аспекты, которые затрагивают все слои (логирование, аутентификация, валидация, кэширование). Часто реализуются через междиаметральное программирование (AOP) или фильтры/ middleware в ASP.NET Core.

Принципы взаимодействия между слоями

1. Однонаправленная зависимость: Зависимости направлены внутрь, к ядру. Слой представления зависит от бизнес-слоя, а бизнес-слой зависит от слоя данных, но не наоборот. Это достигается за счёт инверсии зависимостей (Dependency Inversion Principle, DIP) через интерфейсы.
2. Изоляция изменений: Изменения в одном слое (например, замена СУБД в DAL) минимально затрагивают другие слои.
3. Контракты на основе интерфейсов: Слои общаются через четко определённые интерфейсы, что позволяет легко подменять реализации (например, для юнит-тестирования с использованием Mock-объектов).

Преимущества и недостатки

Преимущества:

• Читаемость и поддерживаемость: Код организован по функциональному признаку.
• Тестируемость: Бизнес-логику можно тестировать изолированно (юнит-тесты), без зависимости от БД или UI.
• Масштабируемость: Слои могут быть физически разделены (разные серверы) при росте приложения.
• Повторное использование: Бизнес-слой может быть использован с разными интерфейсами (Web API, Desktop, мобильное приложение).

Недостатки:

• Сложность (Over-engineering): Для очень простых приложений (CRUD) может показаться избыточной.
• Производительность: Дополнительные уровни абстракции (маппинг DTO) могут незначительно влиять на скорость.
• "Жесткость" классической N-Layer: Приводит к созданию "анаемичных" моделей. Этого избегают в более продвинутых подходах, таких как Чистая архитектура (Clean Architecture) или Вертикальные срезы (Vertical Slices), которые также являются эволюцией многослойного подхода, но с акцентом на домен и гибкость.

В итоге, многослойная архитектура — это проверенный временем паттерн для построения структурированных, надежных и долгоживущих C# backend-приложений, который является отправной точкой для изучения более современных архитектурных стилей.