Роль не даёт права на любой объект
На условной площадке заказчик создаёт проект, исполнитель откликается и выполняет согласованную задачу, а сотрудник поддержки рассматривает обращения в пределах своих полномочий. Но одной надписи заказчик в профиле недостаточно: пользователь должен иметь отношение именно к этому заказу. Чужой заказ не становится доступным только из-за совпадения роли. Вход в учётную запись подтверждает личность пользователя в рамках системы, а проверка прав определяет допустимость конкретного действия. Эти проверки различаются. Даже скрытая в интерфейсе кнопка не заменяет проверку на сервере. Система должна проверять пользователя, объект, действие и необходимые условия каждый раз, когда выполняется значимая операция.
Состояние заказа задаёт возможные переходы
Для учебной модели можно выбрать последовательность: опубликован, исполнитель выбран, в работе, на проверке, принят. Это пример проектирования, а не описание обязательных правил всех бирж. Для каждого перехода нужно назвать инициатора и условие. Передача результата исполнителем и принятие результата заказчиком являются разными событиями. Если результат возвращён на доработку, полезно сохранять, какую версию проверяли и какие замечания относятся к ней. Иначе новая версия может оказаться принята по решению, которое касалось старой. Изменение согласованных условий также требует отдельного понятного процесса. Нельзя считать, что любое редактирование карточки автоматически меняет ожидания уже выбранного исполнителя.
Статус работы не равен статусу расчётов
Завершение задания и движение средств отражают разные процессы. Их связь должна быть явно определена правилами площадки и используемой платёжной системой. Надпись о завершении работы не подтверждает сама по себе фактический платёж. В реальном проекте расчёты, возвраты и обязанности сторон требуют отдельной технической и правовой проработки. Для анализа достаточно отделить эти события и предусмотреть понятную историю действий: кто передал результат, какую версию приняли и когда изменился статус. Поддержке нужны относящиеся к спору сведения, а не неограниченный просмотр любых личных данных. Журнал событий помогает разобраться в последовательности, но не заменяет ясные правила рассмотрения разногласий и ограничения доступа.
Попробуйте на практике
Спроектируйте на бумаге учебный заказ на три простые иллюстрации. Используйте вымышленных участников и не подключайте настоящие платежи.
- Определите двух участников: заказчика этого проекта и выбранного исполнителя. Добавьте третьего пользователя, который не участвует в заказе, и сотрудника поддержки с ограниченной задачей.
- Запишите пять состояний заказа и проведите допустимые переходы. Для каждого подпишите инициатора и необходимое условие.
- Разберите ситуацию: исполнитель передал первую версию, заказчик вернул её с замечаниями, затем появилась вторая. Укажите, какая версия ожидает проверки и какое событие подтвердит её принятие.
- Добавьте три проверки запрета: посторонний пользователь не принимает результат, исполнитель не подтверждает приёмку за заказчика, старое решение не переносится на новую версию без предусмотренного основания.
Как проверить результат. Каждое действие связано с участником, конкретным заказом и состоянием. Передача результата отделена от его принятия, версии различимы, а статус расчётов не выведен автоматически из учебной схемы. Для неопределённых переходов записано, что требуется уточнить.
Частые вопросы
Достаточно убрать лишние кнопки из интерфейса?
Нет. Интерфейс помогает пользователю ориентироваться, но окончательную проверку допустимости действия выполняет сервер. Условия должны применяться последовательно, независимо от способа обращения к функции.
Нужно ли сразу добавлять все возможные функции?
Для начала полезно сделать непротиворечивым основной путь заказа. Дополнительные роли, споры, подписки и другие возможности расширяют число состояний и правил. Их добавляют вместе с понятными ограничениями и проверками, а не только новыми экранами.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.