Какую архитектуру выбрать для системы с задачами, которые требуют множественной обработки/подтверждения?

Question

[SimpleDreamer]

Добрый день!

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

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

Например, задача добавления нового пользователя в систему с разрешением прохода через СКУД.

При добавлении нового пользователя по бизнес-логике
- сначала должен быть сформирована задача менеджером по персоналу
(создает new TASK, привязанную к USER_ID, создавшему задачу. Статус -> "Новая задача"),
- после этого данные из созданной задачи должны пройти сверку с данными из remote DB.
Для этого задача в виде запроса(JSON) передается другому модулю, который обеспечивает эту сверку данных
(статус -> "Ожидание сверки данных").
- В случае успеха сверки данных, запрос отправляется на подтверждение администратору системы
(статус -> "Ожидает проверки администратором", формируется new NOTIFICATION, содержащий TASK_ID и адресуем его администратору).
- После подтверждения администратором, запрос должен быть разбит на запросы конкретным СКУД чтобы прописать нового пользователя в них
(статус -> "Ожидает загрузки в СКУД").
- И лишь после получения подтверждений от СКУД нужно уведомить что пользователь добавлен
(статус -> "Выполнено", формируется new NOTIFICATION, содержащий TASK_ID и адресуем его создателю данного TASK, уведомляя об успешности выполнения).

Структура БД(частичная):
- таблица TASKS(TASK_ID, DESCRIPTION(например в формате JSON), CREATOR_ID(содержит USER_ID того, кто создал данную задачу), STATUS),
- таблица NOTIFICATIONS(NOTIFICATION_ID, DESCRIPTION, TASK_ID(ссылка на задачу, привязанную к уведомлению)),
- таблица USER_NOTIFICATION(USER_ID, NOTIFICATION_ID) - связь many-to-many,
т.к. уведомление может быть адресовано многим юзерам и один юзер может иметь много уведомлений.

Создание задачи заключается в добавлении записи в таблицу TASKS.
Отправка уведомлений осуществляется за счет создания уведомления в таблице NOTIFICATIONS и добавления записи в таблицу USER_NOTIFICATION,
чтобы понимать кому адресовано данное уведомление.

Я так понимаю, для подобного поведения системы должны быть какие-то паттерны проектирования.
Подскажите, пожалуйста, какие, если они существуют?

Возможно я выбрал неправильный путь и нужно как-то по-другому подобное реализовывать.
Подскажите, пожалуйста, в какую сторону посмотреть, что почитать.

Answer 1

[Максим Федоров]

State Machine

Хорошо себя показывает в разного рода CRM, колл-центрах, Order Proceesing в сложных системах.
Из одного состояния можно перейти только в определенные, каждое состояние валидно, открыты только определенные переходы и в целом такой подход к проектированию помогает бороться со сложностью условий и контролем состояний.

Пример схемы 1

Пример схемы 2

Comments

[SimpleDreamer]

Максим, спасибо! Вы мне очень помогли! :-) Для меня важно было понять в правильном ли я направлении думаю. Я как раз и пытался провести некоторую аналогию своей системы с Redmine, понять как там все устроено, чтобы некоторые вещи попытаться использовать у себя. А не подскажете, может есть какие-то базовые учебники/материалы по основам построения CRM систем?

[Максим Федоров]

SimpleDreamer, это дело уже отдельным вопросом лучше обозначить...

[SimpleDreamer]

спасибо! так и сделаю.