Мы разбирали, какие вопросы аналитик должен задать до проектирования отмены заказа.
Теперь давайте зафиксируем один конкретный сценарий, чтобы не пытаться уместить в одну диаграмму вообще всё.
Допустим, мы договорились о таких правилах:
— пользователь может отменить заказ, пока он не передан в доставку;
— отменяем весь заказ целиком;
— если заказ уже оплачен — нужно сделать возврат денег;
— после этого надо снять резерв со склада;
— в конце пользователь должен увидеть, что заказ отменён.
То есть сценарий уже не выглядит как:
«нажал кнопку → заказ отменён»
На самом деле между нажатием кнопки и финальным статусом происходит несколько шагов.
Участники процесса:
User → Order Service → Payment Service → Warehouse Service → Notification Service
Логика примерно такая:
1. Пользователь нажимает «Отменить заказ».
2. Order Service проверяет, можно ли ещё отменить заказ.
3. Если можно — вызывает Payment Service для возврата денег.
4. После успешного возврата вызывает Warehouse Service, чтобы снять резерв.
5. Затем меняет статус заказа на CANCELLED.
6. И отправляет уведомление пользователю.
Вот здесь и появляется смысл sequence diagram.
Она полезна не потому, что «так принято у аналитиков».
Она полезна потому, что сразу показывает:
— кто у нас инициатор;
— кто за что отвечает;
— в каком порядке идут вызовы;
— где есть точки отказа.
Например, очень быстро возникает вопрос:
А что делать, если деньги уже вернули, а склад не ответил?
И вот это уже нормальный аналитический разговор.
Не про кнопку.
А про бизнес-процесс, статусы и консистентность между сервисами.
Ниже — пример такой диаграммы.
Теперь давайте зафиксируем один конкретный сценарий, чтобы не пытаться уместить в одну диаграмму вообще всё.
Допустим, мы договорились о таких правилах:
— пользователь может отменить заказ, пока он не передан в доставку;
— отменяем весь заказ целиком;
— если заказ уже оплачен — нужно сделать возврат денег;
— после этого надо снять резерв со склада;
— в конце пользователь должен увидеть, что заказ отменён.
То есть сценарий уже не выглядит как:
«нажал кнопку → заказ отменён»
На самом деле между нажатием кнопки и финальным статусом происходит несколько шагов.
Участники процесса:
User → Order Service → Payment Service → Warehouse Service → Notification Service
Логика примерно такая:
1. Пользователь нажимает «Отменить заказ».
2. Order Service проверяет, можно ли ещё отменить заказ.
3. Если можно — вызывает Payment Service для возврата денег.
4. После успешного возврата вызывает Warehouse Service, чтобы снять резерв.
5. Затем меняет статус заказа на CANCELLED.
6. И отправляет уведомление пользователю.
Вот здесь и появляется смысл sequence diagram.
Она полезна не потому, что «так принято у аналитиков».
Она полезна потому, что сразу показывает:
— кто у нас инициатор;
— кто за что отвечает;
— в каком порядке идут вызовы;
— где есть точки отказа.
Например, очень быстро возникает вопрос:
А что делать, если деньги уже вернули, а склад не ответил?
И вот это уже нормальный аналитический разговор.
Не про кнопку.
А про бизнес-процесс, статусы и консистентность между сервисами.
Ниже — пример такой диаграммы.