Архитектура веб-приложения для бизнеса: роли, данные и интеграции
Выбор React, PHP или Go редко определяет успех проекта сам по себе. Большая часть дорогих переделок появляется там, где до разработки не договорились о ролях, владельцах данных, статусах процесса и поведении системы при ошибке внешнего сервиса.
Начинайте проектирование с законченного рабочего маршрута, а не со списка экранов.
Для каждой важной сущности назначьте систему-источник и правила изменения.
Первый релиз должен включать эксплуатацию: доступы, журналы, резервное копирование и мониторинг ошибок.
Опишите рабочий маршрут от входа до результата
Для личного кабинета таким маршрутом может быть размещение заказа и получение документов. Для внутреннего портала — создание заявки, согласование и контроль исполнения. У маршрута должны быть начало, ответственный, набор состояний и проверяемый результат.
Экран имеет смысл только внутри действия. Поэтому до макетов фиксируют, кто входит в систему, что видит, какие решения принимает и что происходит после нажатия кнопки. Исключения — отмена, повтор, просрочка и недоступность интеграции — разбирают вместе с основным сценарием.
- Роли и доступные действия
- Состояния объекта и переходы
- Уведомления и сроки
- Исключения и ручная обработка
Разделите бизнес-правила и владельцев данных
Цена может приходить из 1С, контакт — из CRM, а статус пользовательской заявки храниться в новом приложении. Если две системы одновременно меняют одно поле, рано или поздно возникнет конфликт. В архитектурной схеме нужен владелец каждой сущности и направление обмена.
Бизнес-правила размещают на серверной стороне: расчёты, права, лимиты и переходы между статусами нельзя доверять только интерфейсу. Frontend отображает доступное действие, backend повторно проверяет его и сохраняет результат в журнале.
Проектируйте интеграцию вместе с ошибками
Описание API должно включать не только успешный ответ. Нужны таймауты, правила повтора, идемпотентный ключ и понятное состояние для операции, которую внешняя система приняла, но не успела подтвердить.
Онлайн-запрос используют там, где ответ нужен человеку прямо сейчас. Объёмные справочники и некритичные события можно передавать пакетно или через очередь. Такой выбор делают отдельно для каждого потока данных.
- Контракт и версия API
- Ограничение времени ответа
- Повтор без создания дубля
- Очередь необработанных событий
- Операционный экран ошибок
Заложите безопасность в роли и операции
Модель доступа строят вокруг объектов и действий: партнёр видит свои договоры, менеджер — назначенных клиентов, администратор — настройки в пределах своей организации. Одного признака «авторизован» для B2B-системы недостаточно.
Критичные изменения журналируют: кто изменил реквизит, согласовал документ, выдал доступ или повторил обмен. Секреты интеграций хранят вне исходного кода, а чувствительные поля не попадают в обычные технические логи.
Считайте запуск частью разработки
До первого рабочего дня готовят отдельные среды, миграции базы данных, резервное копирование, мониторинг ошибок и порядок отката версии. Команда должна понимать, как увидеть проблему раньше пользователя и кто принимает решение о восстановлении.
Для передачи проекта нужны исходный код, описание переменных окружения, схема данных, API, порядок сборки и список внешних зависимостей. Эти материалы сокращают время следующего изменения и не привязывают продукт к памяти отдельных разработчиков.
Соберите первый релиз вокруг одного результата
Вместо урезанных экранов из всех будущих разделов лучше запустить один маршрут целиком. Например: партнёр входит, видит доступный ассортимент, оформляет заказ, получает статус из 1С и скачивает документ. Такой релиз уже можно проверять на времени операции, ошибках и обращениях пользователей.
Следующие модули добавляют после наблюдения за реальной работой. Архитектура должна позволять это, но оплачивать заранее все возможные сценарии обычно не требуется.