По какому принципу ты бы разделял уровни в приложении?

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

Я разделяю приложение на уровни, руководствуясь принципом разделения ответственности (Separation of Concerns, SoC) и архитектурным паттерном многоуровневой архитектуры (Layered Architecture). Основная цель — создать систему, где каждый слой имеет чёткую зону ответственности, минимизирует зависимости и обеспечивает лёгкость поддержки, тестирования и масштабирования.

Ключевые уровни типичного PHP-приложения

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

Отвечает за взаимодействие с пользователем и отображение данных.

• Контроллеры (Controller) — обрабатывают HTTP-запросы, валидируют входные данные, вызывают бизнес-логику.
• Шаблоны/Представления (View/Template) — формируют HTML, JSON или другие форматы ответа.
• Маршрутизация (Routing) — определяет, какой контроллер обрабатывает запрос.

// Пример контроллера в Laravel
class UserController extends Controller
{
    public function index(UserService $service)
    {
        $users = $service->getAllActive();
        return view('users.index', compact('users'));
    }
}

2. Уровень бизнес-логики (Business Logic Layer)

Содержит ядро приложения — правила, процессы и операции предметной области.

• Сервисы (Service) — инкапсулируют сложную бизнес-логику, координируют работу сущностей.
• Модели предметной области (Domain Model) — объекты, отражающие ключевые концепции бизнеса.
• Важные правила: этот уровень НЕ должен зависеть от фреймворка, базы данных или внешних сервисов.

// Пример сервиса с бизнес-логикой
class OrderService
{
    public function __construct(
        private OrderRepository $repository,
        private PaymentGateway $gateway
    ) {}
    
    public function placeOrder(Cart $cart, User $user): Order
    {
        // Бизнес-правила: проверка доступности товаров
        if (!$cart->allItemsAvailable()) {
            throw new BusinessException('Some items are unavailable');
        }
        
        // Создание заказа по бизнес-правилам
        $order = new Order($user, $cart->getItems());
        $order->applyDiscounts();
        
        // Интеграция с платежной системой
        $transaction = $this->gateway->charge($order->totalAmount());
        
        // Сохранение
        $this->repository->save($order);
        
        return $order;
    }
}

3. Уровень доступа к данным (Data Access Layer)

Абстрагирует работу с хранением и извлечением данных.

• Репозитории (Repository) — предоставляют интерфейс для доступа к данным, скрывая детали реализации.
• Data Mappers/Active Record — преобразуют данные между объектами и БД.
• Unit of Work — управляет транзакциями и целостностью данных.

// Пример интерфейса репозитория
interface UserRepositoryInterface
{
    public function findById(int $id): ?User;
    public function findByEmail(string $email): ?User;
    public function save(User $user): void;
    public function getActiveUsers(int $limit): array;
}

// Реализация для Eloquent ORM
class EloquentUserRepository implements UserRepositoryInterface
{
    public function findById(int $id): ?User
    {
        return UserModel::find($id)?->toDomainEntity();
    }
}

4. Уровень инфраструктуры (Infrastructure Layer)

Содержит технические детали реализации: работу с БД, внешними API, кэшированием, очередями.

• Драйверы баз данных, миграции
• Внешние API-клиенты (для платежных систем, email-сервисов)
• Кэширование, очереди, файловое хранилище

// Пример инфраструктурного сервиса
class StripePaymentGateway implements PaymentGatewayInterface
{
    public function charge(Money $amount): Transaction
    {
        // Детали интеграции с внешним API
        $stripeCharge = StripeClient::createCharge([
            'amount' => $amount->inCents(),
            'currency' => 'usd',
        ]);
        
        return Transaction::fromStripeResponse($stripeCharge);
    }
}

Критические принципы разделения

1. Направление зависимостей — зависимости должны направляться внутрь, к ядру приложения. Уровень бизнес-логики НЕ должен зависеть от внешних слоев.

2. Инверсия зависимостей (DIP) — высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций.

3. Чистая архитектура/Гексагональная архитектура — бизнес-логика в центре, внешние зависимости (БД, фреймворк, UI) на периферии.

Практические преимущества такого разделения

• Тестируемость — бизнес-логику можно тестировать изолированно, без БД или HTTP.
• Заменяемость — можно сменить фреймворк или БД с минимальными изменениями в коде.
• Поддерживаемость — чёткие границы позволяют распределять работу между командами.
• Масштабируемость — слои можно масштабировать независимо (например, вынести бизнес-логику в отдельный микросервис).

Типичная структура проекта

src/
├── Domain/           # Ядро: сущности, бизнес-правила
│   ├── Entities/
│   ├── ValueObjects/
│   └── Services/
├── Application/      # Оркестрация бизнес-сценариев
│   ├── UseCases/
│   └── DTOs/
├── Infrastructure/   # Техническая реализация
│   ├── Persistence/
│   ├── External/
│   └── Cache/
└── Presentation/    # Контроллеры, маршруты, шаблоны
    ├── Controllers/
    ├── Requests/
    └── Resources/

Такой подход требует больше усилий на старте, но окупается при росте приложения, обеспечивая чистую, предсказуемую и гибкую архитектуру, которая может эволюционировать вместе с бизнес-требованиями.