Ваш конспект

Архитектура веб-приложения для SaaS

Ключевые тезисы:

• MVC (Model-View-Controller) — базовая архитектура для разделения ответственности.
• HMVC (Иерархический MVC) — модульная организация кода для больших приложений.
• Контексты (Front, App, Admin, API) — логическое разделение функционала по типам пользователей.
• Сервисы — вынос повторяющейся бизнес-логики, используемой в нескольких местах.
• Провайдеры — абстракция для работы с внешними сервисами, обеспечивающая легкую замену.

Как работает MVC (Model-View-Controller)

MVC — это паттерн, разделяющий приложение на три роли с разной ответственностью.

Пример цикла запроса (страница истории платежей):

1. Роутинг (Route): Запрос по адресу /billing/history передаётся контроллеру BillingHistoryController, методу index.
2. Контроллер (Controller): Выступает "дирижёром". Решает, какие данные нужны (платежи, информация о подписке) и обращается к соответствующим моделям.
3. Модель (Model): Слой работы с данными. Например, PaymentModel знает, как получить платежи из базы данных.
4. Вид (View): Получает данные от контроллера и превращает их в HTML-страницу (таблицы, кнопки).

Преимущества разделения: Изменение шаблона (View) не затрагивает логику работы с данными (Model), и наоборот. Легче ставить задачи и изолировать изменения.

HMVC: Модульная архитектура для SaaS

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

Решение — HMVC:

• Приложение делится на независимые модули (например, Auth, Users, Billing).
• Каждый модуль содержит свой собственный MVC внутри (свои контроллеры, модели, роуты, шаблоны).
• Главное преимущество для AI-кодинга: ИИ, получая задачу в рамках конкретного модуля, изучает его структуру и пишет код, который вписывается в проект, не ломая остальное.

Четыре контекста приложения

Один модуль может работать в разных контекстах (логических зонах):

1. Front : Публичный сайт (лендинг, блог). Доступен без авторизации.
2. App : Личный кабинет зарегистрированного пользователя (дашборд, настройки).
3. Admin : Панель администратора (управление пользователями, аналитика).
4. API : REST API, возвращает JSON. Используется для мобильных приложений и интеграций.

Пример: Модуль User живёт в контексте Admin (админ видит всех пользователей) и в App (пользователь редактирует свой профиль). Используются разные контроллеры и шаблоны, но одна модель User.

Сервисы: Централизация бизнес-логики

Проблема: Одна и та же логика (например, регистрация пользователя) нужна в нескольких контекстах (Front, Admin, API). Если дублировать код, при изменении придётся правлять его везде, что ведёт к багам.

Решение — Сервисы:

• Сервис — это класс с бизнес-логикой, которая не принадлежит конкретной модели (например, UserRegistrationService).
• Он инкапсулирует сложные операции: валидация, вызов моделей, отправка писем, создание настроек.
• Все контроллеры вызывают один сервис. Изменения вносятся в одном месте.

Правило: Создавайте сервис, когда логика нужна в нескольких местах или когда действие затрагивает несколько моделей.

Провайдеры: Абстракция для внешних сервисов

Проблема: Код напрямую обращается к внешнему сервису (например, Mailgun). При его замене нужно переписывать множество мест.

Решение — Провайдеры:

• Провайдер — это прослойка-абстракция. Весь код приложения говорит "отправь письмо", не зная, через какой сервис.
• Конкретная реализация (Mailgun, SendGrid) описывается в одном месте.
• Для замены сервиса меняется только конфигурация провайдера.

Практический пример: Модуль API-ключей

Создан реальный модуль для управления API-ключами в проекте, применяющий все рассмотренные концепции:

• Модуль ApiKeys с контекстами App (пользователь создаёт ключи) и Admin (админ видит все ключи).
• Модель ApiKey для работы с данными.
• Сервис/Фильтр для аутентификации и проверки лимитов запросов.
• Безопасное хранение: В базе сохраняется только хэш ключа, оригинал показывается пользователю единожды.

Как работает аутентификация:

1. Запрос к защищённому эндпоинту проходит через фильтр.
2. Фильтр извлекает ключ из заголовка, ищет его хэш в базе.
3. Проверяет активность ключа и лимиты запросов/расходов.
4. При успехе — пропускает запрос и увеличивает счётчик. При ошибке — возвращает 401 (нет авторизации) или 429 (превышен лимит).

Выводы:
Для создания масштабируемого и поддерживаемого SaaS-приложения необходима чёткая архитектура:

1. MVC как основа.
2. HMVC для модульной организации.
3. Разделение на контексты (Front, App, Admin, API).
4. Вынос общей логики в сервисы.
5. Использование провайдеров для абстракции внешних интеграций.

Эта структура делает код предсказуемым, облегчает разработку с помощью AI и снижает количество ошибок.