В чем отличие слоя бизнес-логики от слоя репозитория?

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

Слой бизнес-логики (Business Logic Layer)

Это ядро приложения, которое инкапсулирует правила, процессы и логику, специфичные для предметной области (домена). Например, в банковском приложении сюда входят правила начисления процентов, проверка достаточности средств для перевода или расчет комиссий. Этот слой отвечает на вопрос "что" должно произойти в системе.

• Содержит сущности (Entities), агрегаты (Aggregates) и сервисы домена (Domain Services).
• Реализует сложные бизнес-правила и инварианты (условия, которые всегда должны быть истинны).
• Не зависит от технических деталей, таких как базы данных, веб-фреймворки или внешние API.

Слой репозитория (Repository Layer)

Это слой доступа к данным (Data Access Layer), который предоставляет абстракцию над механизмом хранения. Его основная задача — изолировать бизнес-логику от деталей работы с базой данных, файловой системой или внешним сервисом. Репозиторий отвечает на вопрос "как" данные сохраняются и извлекаются.

• Предоставляет коллекцие-подобный интерфейс для работы с агрегатами (например, FindById, Save, Delete).
• Скрывает специфику запросов (SQL, NoSQL, вызовы API).
• Может включать кэширование или базовую оптимизацию запросов, но не бизнес-правила.

Пример кода

Рассмотрим простой пример на C# для системы заказов. Сначала определим интерфейс репозитория в слое доступа к данным:

// Repository Layer Interface
public interface IOrderRepository
{
    Order GetById(int id);
    void Save(Order order);
    IEnumerable GetOrdersByCustomer(int customerId);
}

Затем реализуем бизнес-сервис, который использует этот репозиторий, применяя правила домена:

// Business Logic Layer Service
public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public OrderService(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public void PlaceOrder(Order order)
    {
        // Бизнес-правило: сумма заказа должна быть положительной
        if (order.TotalAmount <= 0)
            throw new InvalidOperationException("Order total must be positive.");

        // Бизнес-правило: проверка статуса клиента (упрощенно)
        if (order.Customer.IsBlocked)
            throw new InvalidOperationException("Cannot place order for a blocked customer.");

        // Делегируем сохранение репозиторию
        _orderRepository.Save(order);
        // Здесь могла бы быть дополнительная логика, например, отправка уведомления
    }

    public decimal CalculateCustomerTotalSpent(int customerId)
    {
        // Бизнес-логика: расчет общей суммы потраченных средств
        var orders = _orderRepository.GetOrdersByCustomer(customerId);
        return orders.Where(o => o.IsPaid).Sum(o => o.TotalAmount);
    }
}

В этом примере OrderService содержит бизнес-правила, но для получения данных он полагается на абстракцию IOrderRepository. Реализация репозитория (например, SqlOrderRepository или InMemoryOrderRepository) может быть заменена без изменения кода сервиса.

Ключевые отличия

• Ответственность: Бизнес-логика определяет правила; репозиторий управляет персистентностью (сохранением).
• Зависимости: Бизнес-логика зависит от абстракций репозитория (интерфейсов), но не от их конкретных реализаций или технологий БД.
• Тестируемость: Бизнес-логику легко тестировать с помощью mock- или stub-репозиториев, изолируя её от инфраструктуры.
• Изменчивость: Правила бизнеса меняются по требованиям заказчика; механизм хранения данных может меняться по техническим причинам (миграция БД). Разделение слоев позволяет изменять их независимо.

Вывод: Разделение бизнес-логики и репозитория применяется для создания чистых, тестируемых архитектур, таких как Clean Architecture или Domain-Driven Design (DDD). Оно полезно в любом проекте средней и высокой сложности, где важно обеспечить гибкость и долгосрочную поддерживаемость кода, позволяя изменять правила предметной области или источник данных с минимальными затратами.