Отделение бизнес-правил от бизнес-процессов

Question

как мне вывести бизнес-правила из бизнес-процессов, чтобы я мог добавлять правила, не затрагивая логику бизнес-процесса?

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

Я не собираюсь использовать механизм правил, так как думаю, что это может быть слишком тяжело для моей архитектуры.

Спасибо и всего наилучшего,
Аджай

Answer 1

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

Можно упаковать метод в его собственную библиотеку (dll, jar или что-то еще) и заменить этот jar новой версией. Измените библиотеку, измените бизнес-правила.

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

Если сложность возрастает достаточно, вы обнаружите, что внедрили свой собственный механизм правил.

В какой-то момент становится более эффективным использовать существующий механизм правил, а не изобретать это колесо.

Для получения более подробных советов вам необходимо рассказать нам больше о том, что вы делаете.

Answer 2

Ответ на этот вопрос сложнее, чем я мог бы написать здесь. Это касается науки об отношениях данных, безопасности, доктрины политики и административных ограничений вашего бизнеса / отрасли.

Я мог бы неправильно истолковать ваш вопрос, если вы имели в виду нечто менее расплывчатое, чем "бизнес-правила" и "бизнес-политика".

Answer 3

Вопросы довольно широкие, поэтому я отвечу в общих чертах.

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

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