Workflow
Контролируемые переходы статусов
Изменения статуса заявки проходят через отдельную workflow-логику. Некорректные переходы отклоняются, поэтому произвольное изменение состояния в разных частях приложения не допускается.
← Назад к проектам
Production-проект
Service Desk
Production-ready система управления сервисными заявками на Laravel с акцентом на структурированный жизненный цикл тикетов, права доступа, интеграции, автоматизацию и поддерживаемую backend-архитектуру.
Тип
Система управления сервисными заявками
Основной фокус
Backend-архитектура и интеграции
Статус
Завершён
01 / Проект
Проект
Service Desk — это backend-ориентированное приложение для управления поддержкой и заявками, построенное вокруг структурированного жизненного цикла тикета и чётко разделённых обязанностей пользователей.
Приложение поддерживает три основные роли: Requester, Agent и Administrator. У каждой роли есть собственные права и обязанности в рамках жизненного цикла заявки.
Requester может создавать и отслеживать свои заявки, Agent может работать с назначенными заявками и управлять их продвижением, а Administrator имеет более широкий контроль над пользователями, назначениями и системными операциями.
Проект создавался как реалистичное production-приложение, а не как простой CRUD. Основное внимание уделено предсказуемым бизнес-правилам, поддерживаемому backend-коду, отслеживаемым изменениям, интеграциям и надёжному поведению системы при изменении её состояния.
02 / Основной backend
Основной backend
Ядро приложения построено вокруг явных правил жизненного цикла заявки вместо произвольного изменения статусов напрямую из контроллеров или моделей.
Авторизация
Права на основе ролей
Laravel policies определяют, какие действия Requester, Agent и Administrator могут выполнять с заявками, комментариями, вложениями и операциями жизненного цикла.
Логика приложения
Сервисно-ориентированный подход
Бизнес-операции, такие как переходы статусов, уведомления и внешние интеграции, вынесены в отдельные сервисы, поэтому контроллеры остаются сосредоточены на обработке запросов.
Согласованность
Транзакции базы данных
Операции, изменяющие несколько частей состояния приложения, выполняются внутри транзакций базы данных, чтобы связанные изменения либо завершались вместе, либо полностью откатывались.
Структура домена
Enums и явные состояния
Статусы и приоритеты заявок представлены PHP enums, что уменьшает количество разбросанных строковых значений и делает доменные правила понятнее и проще в сопровождении.
Назначение
Ответственность за заявку
Заявки могут назначаться Agent-пользователям с сохранением связи с исходным Requester, что позволяет системе чётко различать автора заявки и того, кто её обрабатывает.
03 / Аудит и уведомления
Аудит и уведомления
Важные действия с заявками отслеживаются, а уведомления обрабатываются вне основного HTTP-запроса, чтобы бизнес-операции оставались надёжными и отзывчивыми.
История изменений
Понятная история заявки
Изменения заявок записываются в отдельный слой истории с сохранением информации о том, кто выполнил действие, когда это произошло и что именно изменилось.
Вместо показа пользователю сырых значений базы данных приложение преобразует изменения в понятные записи истории, например изменение статуса, назначение исполнителя или обновление приоритета.
Примеры
/
Статус изменён с New на In Progress
/
Заявка назначена Agent-пользователю
/
Приоритет изменён с Medium на High
Совместная работа
Комментарии
Пользователи могут обсуждать ход выполнения заявки прямо внутри приложения, сохраняя коммуникацию привязанной к конкретной заявке и пользователю.
Файлы
Приватные вложения
Вложения заявок хранятся приватно и доступны через авторизацию приложения вместо публикации в виде неограниченно доступных файлов.
Уведомления
Отправка через очередь
Уведомления отправляются через queue, поэтому внешняя доставка не блокирует основной пользовательский запрос.
Надёжность
Побочные действия после commit
Побочные действия, зависящие от сохранённого состояния приложения, выполняются только после успешного завершения транзакции базы данных. Это предотвращает отправку уведомлений об изменениях, которые впоследствии были откатаны.
04 / Интеграции
Интеграции
Внешние системы подключаются через отдельные сервисы приложения и проверяемые входящие endpoints, благодаря чему логика конкретных провайдеров остаётся отделённой от основного домена заявок.
API
REST API
Приложение предоставляет REST API для работы с данными Service Desk вне Blade-интерфейса, при этом повторно используются те же правила авторизации и бизнес-логики, что и в основном приложении.
Jira
Интеграция с Jira
Service Desk может взаимодействовать с Jira через отдельный интеграционный слой, позволяя подключить внешнюю систему отслеживания задач без внедрения Jira-специфичной логики в основной workflow заявок.
GitHub
Интеграция с GitHub
Интеграция с GitHub позволяет событиям репозитория и внешним процессам разработки взаимодействовать с приложением через отдельный сервис провайдера, не связывая их напрямую с моделями и контроллерами заявок.
Webhooks
Проверяемые входящие события
Входящие webhook-запросы проверяются до принятия их payload, поэтому недоверенные запросы не могут быть обработаны как легитимные события внешнего провайдера.
Надёжность
Идемпотентная обработка
Обработка webhook спроектирована так, чтобы выдерживать повторную доставку. Дублирующиеся события провайдера распознаются, поэтому одно и то же внешнее событие не создаёт повторных изменений в приложении.
Архитектура
Изоляция провайдеров
Внешние провайдеры скрыты за отдельными интеграционными границами. Это сохраняет независимость домена приложения и упрощает замену, тестирование и расширение провайдер-специфичной логики.
05 / AI-интеграция
AI-интеграция
AI-функциональность интегрирована как отдельная возможность приложения, а не встроена напрямую в контроллеры заявок и не привязана навсегда к одному внешнему поставщику моделей.
Реализация оставляет AI-сгенерированные предложения под контролем пользователя. Сгенерированный результат может помогать в workflow, но состояние приложения не меняется автоматически без явного действия человека.
Архитектура
Независимый от провайдера дизайн
AI-функциональность предоставляется через абстракцию уровня приложения вместо распределения вызовов SDK конкретного провайдера по всей кодовой базе. Остальная часть приложения зависит от общего интерфейса, а не от одного AI-поставщика.
Провайдеры
OpenAI и Groq
Интеграция поддерживает несколько AI-провайдеров, включая OpenAI и Groq. Провайдера можно менять без необходимости встраивать знание его специфичного API в домен заявок.
Workflow
Human-in-the-loop
Результат AI рассматривается как предложение, а не как авторитетное решение системы. Пользователь проверяет сгенерированный контент и сам решает, должен ли он стать частью реального workflow заявки.
Разделение
AI вне основного домена
Правила workflow заявок остаются детерминированными и независимыми от доступности AI. Если AI-провайдер недоступен, основной Service Desk продолжает работать в обычном режиме.
Принцип проектирования
AI помогает пользователю. Он не становится бизнес-логикой без явного решения человека.
06 / Тестирование и надёжность
Тестирование и надёжность
Автоматические тесты защищают workflow приложения, правила авторизации и интеграции, позволяя вносить изменения без зависимости только от ручной проверки.
Тесты
315
автоматических тестов
Проверки
979
assertions
Pipeline
CI
автоматическая проверка
PHPUnit
Feature и unit тесты
Автоматические тесты проверяют бизнес-поведение на разных уровнях, включая отдельные доменные правила и полные пользовательские сценарии приложения.
Интеграции
Проверка внешнего поведения
Поведение, связанное с интеграциями, тестируется без необходимости подключать реальные сторонние сервисы в каждом тесте, благодаря чему тестовый набор остаётся повторяемым и пригодным для автоматического выполнения.
CI
Автоматическая проверка проекта
CI pipeline запускает автоматические проверки до принятия изменений, добавляя дополнительный уровень безопасности помимо локальной разработки и ручного code review.
Качество кода
Laravel Pint
Laravel Pint используется как часть проверки проекта, чтобы форматирование PHP-кода оставалось единообразным во всей кодовой базе.
Build
Проверка production assets
Frontend production build проверяется вместе с backend-проверками, чтобы deployment не зависел от поведения assets, работающего только в development-среде.
Финальная проверка
315 тестов, 979 assertions, Laravel Pint, production asset build и CI-проверка успешно завершены.
07 / Production и deployment
Production и deployment
Приложение развёрнуто как реальная production-система с постоянным хранилищем, фоновыми процессами, HTTPS и внешней доставкой email.
Хостинг
Deployment на Railway
Приложение развёрнуто на Railway с отдельными процессами основного приложения и background worker.
База данных
MySQL
Production-данные приложения хранятся в MySQL, а migrations используются для поддержания одинаковой структуры базы данных между окружениями.
Фоновые задачи
Отдельный queue worker
Queue jobs выполняются в отдельном worker-процессе, поэтому уведомления и другие асинхронные операции обрабатываются независимо от web-запросов.
Хранилище
Постоянное приватное хранилище
Приватные вложения заявок сохраняются в persistent storage, поэтому загруженные файлы переживают redeploy приложения и при этом остаются защищены авторизацией.
Безопасность
HTTPS и secure cookies
Production-среда использует HTTPS с собственным доменом и безопасной конфигурацией cookie, подходящей для зашифрованных браузерных сессий.
Состояние
Health endpoint приложения
Laravel health endpoint доступен для базовых проверок deployment и доступности приложения.
Доставка через Resend
Транзакционные письма приложения отправляются через Resend с использованием настроенного production sender.
Домен
desk.kotov.lt
Приложение доступно через отдельный собственный поддомен, поэтому это реальное публичное развёртывание, а не только локальная демонстрационная среда.
Production-конфигурация
Railway, MySQL, отдельный queue worker, постоянное приватное хранилище, HTTPS, health checks и транзакционная доставка email.
08 / Технологический стек
Технологический стек
Проект сочетает стандартный Laravel stack с фоновым выполнением задач, внешними интеграциями и инженерными инструментами, ориентированными на production.
Backend
PHP
Laravel
REST API
Laravel Sanctum
Данные
MySQL
Eloquent ORM
Миграции базы данных
Приватное файловое хранилище
Интеграции
Jira
GitHub
OpenAI
Groq
Resend
Инженерные инструменты
PHPUnit
Laravel Pint
Docker
Laravel Sail
CI
09 / Результат
Что демонстрирует этот проект
Service Desk демонстрирует способность проектировать и поддерживать backend-функциональность, выходящую за рамки простых CRUD-операций: явные бизнес-правила, авторизация, асинхронная обработка, интеграции и production deployment.
Проект также охватывает вопросы, которые становятся важными в реальных системах: транзакционную согласованность, аудит, дублирующиеся внешние события, приватный доступ к файлам, автоматическое тестирование и изоляцию сбоев между компонентами приложения.
Структурированные бизнес-процессы
Авторизация на основе ролей
Сервисно-ориентированная backend-архитектура
Надёжные внешние интеграции
Автоматическое тестирование и CI
Production deployment и эксплуатация