Подписание документов — это больше, чем добавление подписи в файл. Надёжный продукт должен сохранять приватность документов и неизменяемые версии, координировать нескольких участников, соблюдать права и порядок подписания и давать командам и интеграциям понятную историю событий. Криптографическая работа конкретного провайдера не должна становиться источником бизнес-истины.
Дмитрий Бруев спроектировал и разработал Signeva как модульное приложение Laravel, где PostgreSQL служит авторитетным хранилищем бизнес-данных. Отдельно развёрнутый движок подписания на Java выполняет ограниченные операции провайдера и криптографии. Hosted Signing UI, версионируемый API и закрытые PHP- и JavaScript-SDK используют ограниченные краткосрочные контракты, не раскрывая браузеру внутренние сервисы и долгоживущие учётные данные.
Реализованный локальный и тестовый продукт охватывает личные и рабочие пространства, приватные документы, последовательные и непоследовательные запросы на подписание, неизменяемую историю версий, аудиторские данные, уведомления, интеграции и операторскую панель. Развёртывание в production, биллинг и рабочий провайдер подписания остаются отдельными этапами, поэтому кейс описывает проверенную продуктовую разработку, а не публичный запуск сервиса.
Signeva — внутренний продукт, а не клиентский заказ. Дмитрий отвечает за архитектуру продукта, backend- и frontend-разработку, интеграцию движка подписания, границы безопасности, автоматизированную приёмку и контейнерную модель поставки. Работа объединяет клиентский продукт, интеграционную платформу и операторскую панель в одной управляемой системе.
Публичный интерфейс продукта объясняет последовательность до того, как пользователю нужно действовать. В приложении личные и рабочие пространства разделяют владение, готовность участников хранится как устойчивое состояние процесса, а каждый принятый результат добавляет новую версию с проверенной контрольной суммой, не заменяя оригинал. Одна модель обслуживает и пользователей сайта, и продукты, подключённые через API.
У каждой части одна зона ответственности и узкий контракт со следующей. Это уменьшает скрытые связи между клиентскими процессами, операциями подписания и поставкой в production.
Laravel и PostgreSQL отвечают за пользователей, рабочие пространства, права, документы, участников, запросы на подписание и аудиторские данные. Redis координирует временные задачи, но не является источником истины.
Движок подписания на Java получает по одной ограниченной технической операции. Приложение принимает результат из аутентифицированного callback или сверки только после проверки связи операции, личности и данных файла.
Неизменяемые образы приложения, проверки здоровья, фоновые процессы, плановая сверка и административная панель с ограниченными возможностями позволяют диагностировать и восстанавливать платформу, не ослабляя права клиентов.
Автоматизированные тесты и приёмка в локальной среде покрывают реализованные процессы продукта, границы доступа, повторы, callback-вызовы и восстановление. Детерминированный программный провайдер и интеграция с тестовой средой Smart-ID служат для разработки и приёмки. Они не подтверждают доступность рабочего production-провайдера подписания, квалифицированных подписей или запущенного коммерческого сервиса.
Расскажите DB Web Solutions, какие данные должны оставаться авторитетными, какие системы участвуют и как сейчас обрабатываются сбои. Дмитрий поможет определить границы и спланировать надёжный путь реализации.
