Какие знаешь типы архитектуры?

Основные типы архитектуры в веб-разработке (Backend PHP)

В контексте Backend-разработки на PHP я выделяю несколько ключевых типов архитектуры, которые применяются на разных уровнях абстракции — от общего подхода к построению приложения до конкретных шаблонов организации кода. Архитектура определяет масштабируемость, поддерживаемость и гибкость системы.

1. Монолитная архитектура (Monolithic)

Это классический подход, где всё приложение — единая, неделимая кодовая база. Все компоненты (логика, БД, UI) тесно связаны.

// Упрощённая структура монолита
app/
├── controllers/ // Контроллеры
├── models/      // Модели БД
├── views/       // Шаблоны
└── config/      // Конфигурация

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

• Простота разработки и деплоя.
• Легкая отладка и тестирование в небольших проектах.
• Минимальные накладные расходы на межпроцессное взаимодействие.

Недостатки:

• Сложность масштабирования (нужно масштабировать всё приложение целиком).
• Запутанность кода при росте проекта (спагетти-код).
• Зависимость от единого стека технологий.

2. Многослойная (N-Layer) и клиент-серверная архитектура

Чаще всего реализуется как трехслойная архитектура (3-tier): презентационный слой (UI), бизнес-логика, слой данных. В PHP-фреймворках (Laravel, Symfony) это естественный подход.

// Пример разделения в Laravel
// Слой данных (Eloquent Model)
class User extends Model {
    protected $table = 'users';
}

// Слой бизнес-логики (Service)
class UserService {
    public function register(array $data): User {
        // Валидация, хеширование пароля, логика регистрации
        return User::create($data);
    }
}

// Презентационный слой (Controller)
class UserController {
    public function store(Request $request, UserService $service) {
        $user = $service->register($request->validated());
        return response()->json($user, 201);
    }
}

3. Сервис-ориентированная архитектура (SOA)

Система делится на набор слабо связанных сервисов, которые общаются по сети (часто через HTTP/AMQP). Каждый сервис отвечает за конкретную бизнес-функцию (например, "Платежи", "Пользователи").

// Пример сервиса "Аутентификация" (упрощённо)
class AuthService {
    public function login(string $email, string $password): ?string {
        // Проверка учетных данных, генерация JWT-токена
        $user = User::where('email', $email)->first();
        if ($user && Hash::check($password, $user->password)) {
            return JWT::encode(['user_id' => $user->id], env('JWT_SECRET'));
        }
        return null;
    }
}
// Другие сервисы вызывают его по REST API или через очередь сообщений.

4. Микросервисная архитектура (Microservices)

Это эволюция SOA, где сервисы ещё более мелкозернисты, автономны и развертываются независимо. Каждый микросервис владеет своей БД и реализуется на оптимальном для задачи стеке.

// Пример: отдельный микросервис "Уведомления" на PHP (Lumen)
// Маршрут в микросервисе
$router->post('/send-email', 'NotificationController@sendEmail');

// Контроллер
class NotificationController {
    public function sendEmail(Request $request) {
        // Логика отправки email через RabbitMQ/Kafka
        $this->queue->publish('email_queue', $request->all());
        return ['status' => 'queued'];
    }
}

Ключевые отличия от монолита:

• Независимое масштабирование (можно масштабировать только сервис уведомлений).
• Отказоустойчивость (падение одного сервиса не ломает всю систему).
• Сложность: требуется orchestration (Kubernetes), мониторинг, межсервисная коммуникация.

5. Архитектура, управляемая событиями (Event-Driven)

Компоненты системы общаются через асинхронные события/сообщения. Это часто используется вместе с микросервисами для декаплинга.

// Пример в Laravel с использованием событий
// Событие
class OrderShipped {
    public function __construct(public Order $order) {}
}

// Слушатель
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        // Отправка email пользователю асинхронно
        Mail::to($event->order->user)->send(new ShippedMail($event->order));
    }
}

// Генерация события в контроллере
event(new OrderShipped($order)); // Не блокирует основной поток

6. Гексагональная архитектура (Hexagonal / Ports & Adapters)

Цель — изолировать ядро бизнес-логики от внешних зависимостей (БД, UI, API). Логика взаимодействует с внешним миром через порты (интерфейсы) и адаптеры.

// Порты (интерфейсы) в ядре
interface UserRepositoryInterface {
    public function findById(int $id): ?User;
}

// Ядро (бизнес-логика)
class UserService {
    public function __construct(private UserRepositoryInterface $repo) {}
    public function getUser(int $id): ?User {
        return $this->repo->findById($id); // Не зависит от реализации БД
    }
}

// Адаптер для Eloquent (инфраструктурный слой)
class EloquentUserRepository implements UserRepositoryInterface {
    public function findById(int $id): ?User {
        return User::find($id); // Конкретная реализация
    }
}

7. Бессерверная архитектура (Serverless)

Backend-логика выполняется в виде функций (AWS Lambda, Google Cloud Functions), которые запускаются по событиям (HTTP-запрос, файл в хранилище). Для PHP это менее традиционно, но возможно через Bref для AWS Lambda.

// Пример функции на PHP с Bref
require __DIR__.'/vendor/autoload.php';
lambda(function ($event) {
    $name = $event['queryStringParameters']['name'] ?? 'мир';
    return [
        'statusCode' => 200,
        'body' => json_encode(['message' => "Привет, $name!"])
    ];
});

Выбор архитектуры

Выбор зависит от:

• Масштаба проекта (стартап vs корпоративная система).
• Команды (опыт, навыки DevOps).
• Требований к масштабированию и отказоустойчивости.
• Бюджета и сроков.

Для большинства PHP-проектов оптимальна многослойная архитектура с элементами гексагональной (через внедрение зависимостей и репозитории). Микросервисы — для высоконагруженных систем с отдельными командами. Монолит приемлем для MVP и небольших проектов. Ключевой тренд — движение к слабой связанности и тестируемости через четкое разделение ответственности.