Помогите программисту CRUD думать о “рабочем процессе одобрения”, [закрытом]

Как многие говорили, его утверждение переводит его в новое состояние.

Я столкнулся с тем, что часто пользователи хотят иметь вещи в одном и том же «состоянии», но также записывают, что в этом состоянии они находятся на другом этапе или задаче. Например, пользователи могут захотеть различать «запрошенные» и «в процессе». С точки зрения утверждения, как запрошенные, так и находящиеся в процессе обработки являются неутвержденными (открытыми). Если что-то переходит из одобренного обратно в неутвержденное (открытое), это может называться «требуется проверка», но это все равно не одобрено.

Вам может понадобиться что-то вроде этого:

Текущая задача: Состояние

Запрошено: открыто

В процессе: открыто

Требуется проверка: Открыто

Утверждено: Утверждено

По прошествии времени Ваши пользователи, вероятно, захотят больше «режимов» или «задач». Если вы создадите состояние для каждого из них, вы можете получить гораздо большую сложность, чем вы или они действительно хотели. Если вы позволите пользователям иметь столько «режимов» или «задач», сколько они хотят, с отношением «многие к одному» с состояниями, это будет проще с вашей точки зрения, но более точным с точки зрения пользователя.

Это приходило к нам так часто, что мы создали общую систему маршрутизации. Вероятно, это перебор для того, что вы делаете, но вы можете использовать его для поиска идей. Он позволяет направлять произвольный контент произвольным пользователям, используя цепочку (последовательное утверждение) или звездочку (широковещательную рассылку) с минимальным количеством голосов для утверждения. Здесь - автоматически сгенерированный ERD схемы.

В основном у нас есть схема маршрутизации, которая содержит один или несколько списков схем маршрутизации. Каждый список может быть цепочкой или звездочкой, а вся схема может быть инициирована цепочкой или звездочкой. У каждого списка и всей схемы может быть свой голос_то_апрове. Это означает, что у вас может быть схема типа «звезда» с двумя списками, одной звездочкой и одной цепочкой. У всей схемы может быть значение void_to_approve, равное 1, поэтому, если любой список одобряет, одобряется весь рабочий процесс. В цепном списке может быть void_to_approve, равное количеству участников, так что каждый участник должен утвердить, прежде чем следующий участник сможет проголосовать, а первый, кто отклонил, уничтожает этот список. В звездном списке у вас может быть значение Voices_to_approve, равное 1, так что любой в этом списке может мгновенно утвердить весь рабочий процесс

. Эти схемы сохраняются на неопределенный срок и могут быть повторно использованы после настройки. Для реализации схемы делается запись в таблице маршрутизации с использованием scheme_id, объекта, который нужно маршрутизировать, и некоторых деталей, таких как текст утверждения и неодобрения. Таблицы "routing_" затем сохраняют состояние реализованной схемы.

Мы используем систему событий между приложениями для отправки электронных писем или информирования других приложений об изменении состояния маршрута.

Для этого есть шаблоны проектирования. Может быть, они немного помогут:

http://en.wikipedia.org/wiki/Workflow_patterns

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

Что касается моделирования данных, у вас может быть таблица всех «утверждений» с полем состояния, которое является внешним ключом к таблице состояний.

Что касается уведомлений, это то, что ваше приложение должно будет делать, когда оно изменяет состояние утверждения, ему нужно будет искать где-нибудь еще, чтобы узнать, кого / что нужно уведомить для определенного изменения состояния (так что у вас будет чтобы отслеживать, какие сущности получают уведомления о каких изменениях состояния).

Утверждение == Изменение состояния

Изменение состояния == Обновление объекта, который изменил && Создание журнала для записи того, что что-то изменилось.

Вот и все.

Интересные правила: «Кому разрешено выполнять обновление?», «Какие изменения состояния являются юридическими обновлениями?» И «Какие состояния являются тупиковыми?»

Вы строите конечный автомат. Состояние - это атрибут объекта. Вы проталкиваете что-то «через рабочий процесс», обновляя его состояние.

Сейчас я работаю в подобном проекте (другая платформа / БД).

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

Однако для ряда конструкций у меня есть «код состояния» конструкции, который затем определяет (опять же, в коде), кто что может делать с этой конструкцией, и в какие коды состояния они могут ее переместить.