Описать жизненный цикл заказа диаграммой состояний — состояния, переходы, события и условия — и вывести из неё правила API: что разрешено в каком статусе и что вернуть при запрещённом переходе.
Статусы и переходы
Жизненный цикл заказа
Диаграмма состояний (UML 2.5.1) описывает жизнь одного объекта — у нас заказа. Состояние — устойчивая ситуация: заказ оплачен, заказ в сборке. Переход — стрелка между состояниями с подписью «событие [условие] / действие», например «отмена [до передачи курьеру] / запросить возврат». Условие в квадратных скобках называют сторожевым (guard): пока оно ложно, переход не срабатывает. Начальное состояние — закрашенный кружок, конечное — кружок в кольце.
У заказа «Ромашки» шесть статусов: created (создан), paid (оплачен), assembling (в сборке), in_delivery (в доставке), delivered (доставлен), cancelled (отменён). Конечные — delivered и cancelled. Возврат после доставки — отдельный процесс, на этой диаграмме его нет. Все переходы и кто их запускает — в таблице ниже.
Что диаграмма даёт аналитику:
• список разрешённых переходов — готовые правила для API и проверок данных;
• всё, чего нет на диаграмме, запрещено: обратного хода delivered → paid не бывает, а отмену в in_delivery контракт отклоняет кодом 409 Conflict с текущим статусом в теле ошибки;
• каждый переход публикует событие-факт: OrderPaid, OrderCancelled. Бывают события и без смены статуса: OrderReadyForPickup — заказ собран и ждёт курьера.
Повторная отмена уже отменённого заказа — не переход, а повтор: 200 с тем же заказом, без второго возврата. 409 — для in_delivery и delivered.
Статус называет ситуацию, а не команду: paid, а не pay. И он точен настолько, чтобы на нём держались правила: по in_delivery видно, что заказ у курьера, а по общему in_progress — нет.
Таблица переходов
| Из | Событие [условие] / действие | В |
|---|---|---|
| created | оплата прошла (webhook провайдера) | paid |
| created | оплата отклонена или отмена клиентом | cancelled |
| paid | магазин принял заказ | assembling |
| paid | отмена клиентом / возврат денег | cancelled |
| assembling | курьер забрал заказ | in_delivery |
| assembling | отмена клиентом или магазином [до передачи курьеру] / возврат денег | cancelled |
| in_delivery | курьер вручил заказ | delivered |
Конспект урока
Жизненный цикл заказа
Диаграмма состояний (UML 2.5.1) описывает жизнь одного объекта — у нас заказа. Состояние — устойчивая ситуация: заказ оплачен, заказ в сборке. Переход — стрелка между состояниями с подписью «событие [условие] / действие», например «отмена [до передачи курьеру] / запросить возврат». Условие в квадратных скобках называют сторожевым (guard): пока оно ложно, переход не срабатывает. Начальное состояние — закрашенный кружок, конечное — кружок в кольце.
У заказа «Ромашки» шесть статусов: created (создан), paid (оплачен), assembling (в сборке), in_delivery (в доставке), delivered (доставлен), cancelled (отменён). Конечные — delivered и cancelled. Возврат после доставки — отдельный процесс, на этой диаграмме его нет. Все переходы и кто их запускает — в таблице ниже.
Что диаграмма даёт аналитику:
• список разрешённых переходов — готовые правила для API и проверок данных;
• всё, чего нет на диаграмме, запрещено: обратного хода delivered → paid не бывает, а отмену в in_delivery контракт отклоняет кодом 409 Conflict с текущим статусом в теле ошибки;
• каждый переход публикует событие-факт: OrderPaid, OrderCancelled. Бывают события и без смены статуса: OrderReadyForPickup — заказ собран и ждёт курьера.
Повторная отмена уже отменённого заказа — не переход, а повтор: 200 с тем же заказом, без второго возврата. 409 — для in_delivery и delivered.
Статус называет ситуацию, а не команду: paid, а не pay. И он точен настолько, чтобы на нём держались правила: по in_delivery видно, что заказ у курьера, а по общему in_progress — нет.