Давно хотел написать статью про "движок правил", но мучился с нехваткой времени. Недавно я разобрался в использовании и принципах движка, который я разработал для своих товарищей по команде, и просто воспользовался этой возможностью, чтобы записать здесь наш опыт. Вообще говоря, система «механизм правил» больше используется для контроля рисков, но после расследования мы обнаружили, что на самом деле в бизнес-системе существует большее стремление к системе механизма правил, и даже я вижу это на пульсе. Несколько человек спрашивали о том, как должна быть спроектирована и подключена система механизма бизнес-правил.
Сначала поговорим о болевых точках. Почему существует такая жажда систем правил?
недостаток
Сложные бизнес-условия
Только представьте, или что вы испытали, в нашей бизнес-логике есть много-много суждений о бизнес-условиях, и эти бизнес-условия часто изменяются чаще. , один час развертывания».
Частая модификация бизнес-конфигурации
В наш бизнес часто встроено множество бизнес-конфигураций, таких как переключатели функций, белые списки, черные списки и т. д. Для этих конфигураций, если у вашего проекта есть доступ к некоторым системам бизнес-конфигурации, это нормально, если нет, то вам нужно отправить волну кода.
Бизнес-консультирование
Код невидим для нашей бизнес-стороны, и с техническим персоналом всегда консультируются, когда есть что-то, что вообще не является проблемой. И если вы разбираетесь в проекте, это нормально, но как только вы его забудете, вам нужно снова разобраться с бизнес-логикой.
Счастливые семьи всегда похожи друг на друга, а несчастливые — разные. Решение этих, казалось бы, непреднамеренных маленьких проблем всегда непреднамеренно прерывает наше мышление. Мир давно страдает. Чтобы разобраться, нам нужно решить как минимум 3 вещи:
- Настраиваемые бизнес-правила. Написание кода правила поддерживает подключение и горячее обновление.
- Визуализация конфигурации бизнеса. Конфигурация бизнеса должна выполняться самой деловой стороной.
- Бизнес-консалтинг Видимость. Когда бизнес сталкивается с неясной проблемой, он может где-то четко понять причину.
После исследования мы обнаружили, чтоMVELруководствоВыражения идеально подходят для этого. поддерживаяMVELМы думаем, что в системе выражений механизма правил с открытым исходным кодомeasy-rulesБольше подходит для нашей сцены, с одной стороны поддерживаетMVEL, с другой стороны, он также поддерживаетJavaна заказRule, Кроме того, он также поддерживает пользовательский механизм правил.
Однако только поeasy-rulesЕго нельзя использовать непосредственно в производственной среде.Нам нужно внести некоторые коррективы для нашего собственного бизнеса, такие как необходимость унифицированных правил, необходимость унифицированного внедрения атрибутов, необходимость унифицированной структуры возврата и так далее.
Мы примерно нарисовали основной процесс ведения нашего бизнеса. Первое, что нужно отметить, это то, что в бизнесе обязательно будут разные сценарии, поэтому нам нужно хорошо поработать над сегментацией сценариев, и мы не можем выполнить все в одном месте. Поэтому я разработал его для справки в некоторых местахJava I/OИдея дизайна этой части имеетEngineProvidersОтвечает за планирование распределения по различным сценариям.
Каждая сцена реализует унифицированный интерфейс, а процесс планирования также динамичен, с минимальным количеством операций для наших студентов-разработчиков.
До этого должен быть единыйEngineServiceДавайте получим правила, которые мы настроили унифицированным образом, и внедрим их в сцену. В то же время нам также необходимо внедрить нашу пользовательскую бизнес-конфигурацию в наш источник данных. Как показано ниже:
Вот некоторые из правил, которые мы настроили.Из-за деловых отношений были добавлены некоторые мозаики, но это не должно мешать пониманию, что здесь делать.
Однако в реальном бизнесе нам по-прежнему нужны абстрактные унифицированные правила во многих местах, поэтому мы также можем использоватьeasy-rulesПредоставляет возможность помочь нам выполнить такого рода вещи.
Конечно, следует отметить, что есть еще некоторые детали, которые не были добавлены, например, параметры конструкции.builderИ т. д., потому что он настроен в соответствии с нашим бизнесом, поэтому, даже если он добавлен, он не имеет большой справочной ценности.
И последнее, но не менее важное: необходимо решить проблему визуализации причины. На самом деле это относительно просто, нам нужно только записать текущие параметры и правила блокировки в месте блокировки, а затем визуализировать их, а бизнес-сторона может проверить их самостоятельно.
Добро пожаловать, чтобы обратить внимание на мой публичный аккаунт, по крайней мере, еще одна подробная оригинальная статья каждую неделю: