Для чего нужно отделение бизнес-логики от представления?

Архитектурный принцип разделения ответственности

Отделение бизнес-логики (domain layer) от представления (presentation layer) — это фундаментальный принцип проектирования ПО, который лежит в основе большинства современных архитектурных паттернов (MVC, Clean Architecture, Hexagonal Architecture). Цель — создание масштабируемого, поддерживаемого и тестируемого кода.

---

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

1. Поддерживаемость и эволюция кода

• Изоляция изменений: При изменении правил бизнеса (например, расчёт скидок) правки вносятся в одном месте — в слое бизнес-логики. Представление (HTML, JSON-ответы API) остаётся нетронутым. И наоборот, смена дизайна или формата вывода (веб-интерфейс на API) не затрагивает ядро приложения.
• Читаемость: Код становится предсказуемым. Логика предметной области не загрязнена деталями отображения (echo, HTML-теги), что упрощает её понимание и анализ для новых разработчиков.

2. Тестируемость

Слой бизнес-логики, будучи изолированным от фреймворков, баз данных и HTTP-запросов, можно легко покрывать модульными и интеграционными тестами. Тестировать чистую PHP-логику в разы проще, чем логику, вплетённую в шаблоны или контроллеры фреймворка.

// ПЛОХО: Логика и представление смешаны (не тестируемо)
class BadController {
    public function calculateDiscount($price, $userType) {
        $discount = 0;
        if ($userType == 'vip') {
            $discount = $price * 0.2; // Бизнес-правило
        }
        echo "<div>Цена со скидкой: " . ($price - $discount) . "</div>"; // Представление
    }
}

// ХОРОШО: Логика отделена (легко тестировать)
class DiscountCalculator {
    public function calculateForUser(float $price, string $userType): float {
        if ($userType === 'vip') {
            return $price * 0.2; // Чистая бизнес-логика
        }
        return 0.0;
    }
}
// Этот класс можно протестировать БЕЗ вывода в браузер.

3. Переиспользование (Reusability)

Одна и та же бизнес-логика может использоваться в разных контекстах представления без дублирования кода. Например:

• Веб-интерфейс (HTML)
• REST API (JSON/XML)
• Консольные команды (CLI)
• Фоновые задачи (воркеры, очереди)

// Слой бизнес-логики (единый для всех представлений)
class OrderService {
    public function createOrder(Cart $cart): Order { ... }
}

// Разные точки входа используют одну логику
$orderService = new OrderService();

// Веб-контроллер
class OrderController {
    public function store(Request $request, OrderService $service) {
        $order = $service->createOrder($request->getCart());
        return view('order.confirmation', ['order' => $order]);
    }
}

// API-контроллер
class ApiOrderController {
    public function store(ApiRequest $request, OrderService $service) {
        $order = $service->createOrder($request->getCart());
        return response()->json($order);
    }
}

// Консольная команда
class ProcessBatchCommand {
    public function handle(OrderService $service) {
        $order = $service->createOrder($this->getBatchCart());
        $this->info("Order {$order->id} created.");
    }
}

4. Снижение связанности (Low Coupling) и гибкость

Слои общаются через чёткие контракты (интерфейсы, DTO), а не через жёсткие зависимости. Это позволяет:

• Легко менять базу данных, фреймворк представления или внешний сервис.
• Разрабатывать слои параллельно разным командам (backend + frontend).
• Внедрять новые технологии (например, переход от монолита на микросервисы) с минимальными изменениями в ядре.

5. Безопасность

Концентрация критически важных правил (проверка прав доступа, валидация финансовых операций) в одном слое минимизирует риск уязвимостей из-за ошибок в представлении. Контроль доступа (ACL) часто реализуется именно на уровне бизнес-логики, а не в шаблонах.

---

Как добиться разделения на практике (в PHP)

• Используйте паттерн MVC (и его вариации): Контроллер получает запрос, делегирует выполнение бизнес-логики Сервисным классам (Service Layer) или Моделям предметной области (Domain Models), а затем передаёт результат в Представление (View).
• Применяйте принципы SOLID, особенно Single Responsibility (единая ответственность) и Dependency Inversion (инверсия зависимостей).
• Выделяйте слой Сервисов (Application Layer): Классы, которые координируют работу сущностей (Entities) и объектов-значений (Value Objects) для выполнения пользовательских сценариев (Use Cases).
• Работайте с DTO (Data Transfer Objects): Используйте простые объекты для передачи данных между слоями, вместо массивов или сырых сущностей.
• Внедряйте зависимость (Dependency Injection): Это позволяет "внедрять" сервисы бизнес-логики в контроллеры, обеспечивая слабую связанность.

Вывод

Отделение бизнес-логики — это не просто "хороший тон", а стратегическая инвестиция в жизненный цикл приложения. Оно прямо ведёт к:

• Снижению стоимости поддержки и развития.
• Повышению скорости разработки за счёт параллельной работы и надёжных тестов.
• Уменьшению количества ошибок и упрощению их поиска.
• Созданию гибкой системы, способной адаптироваться к меняющимся бизнес-требованиям и технологическим трендам.

Игнорирование этого принципа ведёт к созданию "спагетти-кода", где любое изменение становится рискованной операцией, а тестирование — практически невозможным.