Домашнее задание (Pre-work)

Это задание — часть вводного видео курса. Мы собрали его в текстовом виде, чтобы вам не нужно было каждый раз пересматривать видео, чтобы вспомнить условие.

Важно перед началом

  • Задание не проверяется и не оценивается. 

  • Единственно правильного решения не существует. 

  • Вы ещё не изучали большинство инструментов, которые понадобятся для «идеального» решения — это нормально и ожидаемо. 

  • Цель — попробовать порассуждать так, как рассуждает системный аналитик, ещё до старта обучения. Ход мыслей здесь важнее итоговой формулировки. 

  • Сохраните свой результат. Будет интересно вернуться к нему ближе к концу курса и увидеть, как изменился ваш подход.

Контекст задачи

Представьте, что вы работаете системным аналитиком в команде мобильного приложения доставки еды.
К вам приходит бизнес и говорит:

«Нам необходимо добавить возможность оплачивать заказ банковской картой».

Ваша задача — превратить эту короткую фразу в проработанное техническое решение. Разбейте её на три части ниже.

Часть 1. Сценарии

Happy Path (успешный сценарий)

Пользователь сформировал заказ, выбрал оплату картой и нажал кнопку «Оплатить». Распишите, что должно произойти дальше:

  • Куда отправляется запрос?
  • Когда создаётся платёж?
  • В какой момент деньги считаются успешно списанными?
  • Когда заказ должен получить статус «Оплачен»?
  • Что в итоге увидит пользователь на экране?

Negative Path (нештатные сценарии)

Продумайте минимум два негативных сценария:

1. На карте недостаточно средств.

  • Что должна сделать система?
  • Что увидит пользователь?
  • Можно ли повторить попытку оплаты? Какой статус будет у платежа?

2. Платёжный шлюз не отвечает (timeout).

  • Считать платёж неуспешным, оставить в промежуточном статусе или попытаться узнать его состояние позже?
  • Предложите свой вариант.

Усложнение (по желанию)

Что произойдёт, если пользователь очень быстро дважды нажмёт кнопку «Оплатить»? Должна ли система создать два платежа? Если нет — каким образом этого избежать?

Часть 2. API

Придумайте простой API для создания платежа:

POST /payments

Что отправить в запросе?

Подсказка: вероятно понадобятся order_id, amount и currency — но подумайте, нужны ли ещё какие-то данные.

Что вернуть в ответе?

  • Нужен ли payment_id?
  • Нужен ли статус платежа?
  • Какой HTTP status code вернуть при успешном создании платежа?
  • Какой код вернуть, если указанного заказа не существует?
  • Что вернуть, если запрос составлен некорректно?

Если не уверены — посмотрите, как отвечают реальные платёжные API, например Stripe, ЮKassa или CloudPayments.

Часть 3. Схема взаимодействия

Участники схемы:

  • Пользователь
  • Мобильное приложение
  • Backend сервиса доставки
  • Платёжный шлюз

Нарисуйте стрелками, кто кому и что отправляет во время оплаты:

  • Кто инициирует процесс?
  • Когда backend обращается к платёжному шлюзу?
  • Как ответ возвращается обратно?
  • Что происходит после успешной оплаты?

Пример одной стрелки:

Mobile App → Backend: POST /payments { order_id, amount, currency }

Инструмент не важен — подойдёт Miro, PlantUML или обычный лист бумаги.

Что делать с результатом

  1. Сохраните то, что у вас получилось — в любом виде: текст, скриншот схемы, файл.
  2. Если по ходу задания возникли вопросы — запишите их. Скорее всего, ответы найдутся уже в первых модулях курса.

До встречи на курсе в сентябре. Добро пожаловать в системный анализ!