Sobes.tech
Middle+

Задача № 4 (проектиране на интеграция в системната архитектура) Вие сте системен анализатор за откриване на сметки за юридически лица. Получена е задача от бизнес клиента: реализиране на услуга за откриване на сметка. Услугата за откриване включва създаване на договор и резервиране на сметка. При откриване на сметката успешно е създаден договорът на клиента (запазен в базата данни). Услугата за резервиране върна техническа грешка. Какви изисквания, като системен анализатор за откриване на сметки за юридически лица, бихте представили на FP Договор и FP Резервация? Варианти за реализиране на сценария за интеграция, като се вземе предвид разпределена микросервизна архитектура. (Диаграма на последователността "Откриване на разплащателна сметка за ЮЛ" с стъпки на взаимодействие между Клиента, уеб приложението, оркестратора за откриване на сметки за ЮЛ, FP Договор и FP Резервация)

sobes.tech AI

Отговор от AI

В описанной ситуации, где при открытии счета договор создаётся, а резервирование счета завершается ошибкой, необходимо обеспечить согласованность данных и корректную обработку ошибок в распределённой микросервисной архитектуре.

Требования к ФП Договор:

  • Поддержка транзакционной целостности или компенсационных операций (например, отмена созданного договора при ошибке резервирования).
  • Возможность отката изменений (удаление или аннулирование договора) по запросу оркестратора.
  • Идемпотентность операций создания договора, чтобы избежать дублирования при повторных вызовах.

Требования к ФП Резервирование:

  • Чёткая обработка ошибок с информативными кодами и сообщениями.
  • Возможность повторного вызова операции резервирования без негативных последствий (идемпотентность).

Варианты реализации интеграционного сценария:

  1. Оркестрация с компенсационными транзакциями (SAGA):

    • Оркестратор вызывает создание договора.
    • При успешном создании договора вызывает резервирование счета.
    • Если резервирование не удалось, оркестратор инициирует компенсационную операцию — отмену договора.
  2. Использование очередей и событий (Event-driven):

    • Создание договора и резервирование счета выполняются как отдельные события.
    • При ошибке резервирования публикуется событие отмены договора.
  3. Идемпотентные операции и повторные попытки:

    • Оркестратор повторяет вызов резервирования с контролем состояния.
    • При длительной ошибке инициируется компенсация.

Диаграмма последовательности должна отражать эти шаги, показывая вызовы от клиента к веб-приложению, далее к оркестратору, который последовательно взаимодействует с ФП Договор и ФП Резервирование, обрабатывая ошибки и выполняя компенсации.