Правила движка - плюсы и минусы - PullRequest
64 голосов
/ 30 октября 2008

Я проверяю проект, который использует то, что называется Rules Engine . Короче говоря, это способ вывести бизнес-логику из кода приложения.

Эта концепция совершенно новая для меня, и я довольно скептически к ней отношусь. Услышав, что за последние несколько лет люди говорили о моделях анемичных доменов , я подвергаю сомнению подход механизма правил. Мне они кажутся отличным способом ослабить модель предметной области. Например, скажите, что я делаю Java-приложение, взаимодействующее с движком правил. Затем я решаю, что хочу иметь приложение для Android на основе того же домена. Если я не хочу, чтобы приложение Android также взаимодействовало с движком правил, мне придется пропустить любую уже написанную бизнес-логику.

Поскольку у меня пока нет с ними опыта, просто любопытство, мне было интересно услышать о плюсах и минусах использования механизма правил? Единственный профессионал, о котором я могу подумать, это то, что вам не нужно перестраивать все приложение целиком, чтобы просто изменить какое-то бизнес-правило (но на самом деле, сколько приложений действительно имеет столько изменений?) Но использование механизма правил для решения этой проблемы для меня звучит как наложение бинта на рану дробовика.

ОБНОВЛЕНИЕ - с момента написания этого, сам бог, Мартин Фаулер, писал об использовании механизма правил .

Ответы [ 12 ]

1 голос
/ 22 марта 2012

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

Во-вторых, из моего POV, анемичная модель - это не та модель, которая легка в реализации поведения, а та, которая легка в поведении самой . Фактический метод, который описывает доступное поведение в объекте модели домена, не должен выполняться самим объектом.

0 голосов
/ 10 июня 2014

Самым сложным из моего опыта в Rule Engines является то, что:

  1. из OOP POV реорганизация и тестирование правил, написанных на декларативном языке, вызывает большие трудности, в то время как вы реорганизуете код, который их затрагивает.
  2. Часто мы всегда должны думать о порядке выполнения правил, который превращается в беспорядок, когда их много.
  3. Некоторые незначительные изменения могут вызвать некорректное поведение правил, приводящее к ошибкам в работе. На практике не всегда возможно охватить все случаи испытаниями заранее.
  4. Правила, изменяющие объекты, используемые в других, также увеличивают сложность, заставляя разработчиков разбивать их на этапы.
...