Статьи

Внешняя логика приложения: подход бизнес-правил с Drools

Декабрь 4, 2018

Первоначально я написал этот пост в блоге нашей компании, и я решил поделиться им здесь, как моя первая статья. Этот раздел посвящен экстернализации логики приложения с помощью подхода бизнес-правил с использованием механизма бизнес-правил Drools. 

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

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

Что такое бизнес-правила?

Бизнес-правило — это просто утверждение, которое определяет или ограничивает некоторые аспекты бизнеса. Бизнес-правила всегда разрешаются в true или false. Бизнес-правило также может быть определено как абстракция политики и практики бизнес-организации.

Пример:

  • У клиента может быть несколько бронирований, но одновременно можно арендовать только один автомобиль. (Прокат автомобилей)
  • Когда регистрация идет из страны, указанной в списке запрещенных стран, отклоните регистрацию. (Регистрация сайта PTC)

Что такое механизм правил?

Механизм бизнес-правил — это сердце технологии, лежащей в основе подхода бизнес-правил. Это система, которая оценивает и выполняет одно или несколько бизнес-правил в производственной системе времени выполнения на основе известных фактов (моделей предметной области).

Зачем использовать механизм правил?

  • Логика и разделение данных — ваши данные находятся в объектах вашего домена, логика в правилах.
  • Скорость и масштабируемость — механизм бизнес-правил использует дизайн алгоритмов для эффективного сопоставления шаблонов правил с объектами вашего домена, например, с  алгоритмом  повторного использования, который используется в Drools Expert. Также с точки зрения масштабируемости правила могут совместно использоваться в различных системах, что позволяет нам создавать или интегрировать подсистемы, которые используют некоторые правила, используемые другими подсистемами.
  • Централизация знаний — поскольку логика выводится в виде правил, существует только один источник истины, а это ваше хранилище правил / знаний (база знаний).
  • Средство объяснения — системы правил эффективно предоставляют «средство объяснения», позволяя регистрировать решения, принятые механизмом правил, а также причины их принятия.
  • Понятные правила — в Drools Expert правила могут быть написаны с использованием DSL (домен-специфических языков), позволяющих нетехническим экспертам в области писать правила, близкие к естественному языку.

Типовые правила

Типовые правила 
 

Рисунок 1: Пример файла правил Drools

Правило сообщения Hello и правила сообщения Goodbye. Мы можем прочитать эти правила следующим образом:

  • Hello Message Rule — «Когда статус объекта Message — HELLO, отобразите атрибут сообщения объекта Message и измените его сообщение и статус на« Goodbye Cruel World »и GOODBYE соответственно».
  • Правило Goodbye Message — «Когда статус объекта Message -« GOODBYE », отобразите атрибут сообщения объекта Message».

Сделайте свои приложения управляемыми правилами

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

  1. Факты — факты — это просто ваши доменные объекты / модели. Правила запускаются против этих фактов, чтобы сопоставить условия, объявленные в правилах, с состоянием факта, который используется в настоящее время, и это определяет правило / правила для выполнения.
  2. Правило — правило — это утверждение, которое проверяет условие на факт и состоит из 3 важных разделов:

    1. Имя — название правила
    2. LHS (Условие) — это раздел «когда» (см. Выше). В этом разделе объявляется условие, которое будет проверять правило.
    3. RHS (Последствие / Действие — это раздел «тогда» (см. Выше). В этом разделе объявляются последствия или действие, которое должно выполняться при выполнении условия, объявленного в разделе «когда».
  3. База знаний — хранилище правил / знаний
  4. Сеанс знаний — сеанс — это установленное взаимодействие между вашим приложением и механизмом правил. Сеанс создается из базы знаний и может быть без сохранения состояния или с сохранением состояния. Приложение использует установленный сеанс для запуска движка против вставленных фактов. 

Пример кода:

package com.ideyatech.drools;

import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatelessKnowledgeSession;

import com.ideyatech.drools.bean.Message;

public class Main {

	public static void main(String[] args) {
		final KnowledgeBase knowledgeBase =
			createKnowledgeBase();
		final StatelessKnowledgeSession session =
			knowledgeBase.newStatelessKnowledgeSession();

		try {
			final Message message = new Message();
			message.setStatus(Message.HELLO);

			session.execute(message);
		}catch (Throwable e) {
			e.printStackTrace();
		}
	}

	private static KnowledgeBase createKnowledgeBase() {
		final KnowledgeBuilder builder = createKnowledgeBuilder();
		final KnowledgeBase knowledgeBase = KnowledgeBaseFactory
			.newKnowledgeBase();
		knowledgeBase.addKnowledgePackages(
				builder.getKnowledgePackages());

		return knowledgeBase;
	}

	private static KnowledgeBuilder createKnowledgeBuilder() {
		final KnowledgeBuilder builder =
			KnowledgeBuilderFactory.newKnowledgeBuilder();
		final String rulePath = "com/ideyatech/drools/rule/hello-world-rule.drl";

		builder.add(ResourceFactory.newClassPathResource(
				rulePath), ResourceType.DRL);
		if (builder.hasErrors()) {
			throw new RuntimeException(builder.getErrors().toString());
		}
		return builder;
	}
}

 Объяснение кода:

  • Приведенный выше код содержит два вспомогательных метода: createKnowledgeBuilder () и createKnowledgeBase ().
  • Метод createKnowledgeBuilder () создает экземпляр KnowledgeBuilder, который отвечает за получение исходных файлов, таких как файлы .drl (Drools Rule), и превращение их в KnowledgePackage определений правил и процессов, которые может использовать база знаний.

    • В этом методе мы добавили в KnowledgeBuilder файл правил «hello-world-rule.drl», который является ресурсом ClassPath. Обратите внимание, что правила также могут быть получены как ресурс File или URL-ресурс.
  • Метод createKnowledgeBase () создает экземпляр KnowledgeBase, который является хранилищем всех определений знаний приложения. Этот метод использует createKnowledgeBuilder () и получает все пакеты знаний из созданного KnowledgeBuilder для использования созданной базой знаний.
  • В основном методе после создания нашей базы знаний мы создали StatelessSession и затем попросили созданный сеанс выполнить все правила для объекта Message со статусом Hello.

Когда мы запускаем этот код, это дает следующий результат:

 Результат выполнения кода

Человекочитаемые правила с использованием DSL

В Drools правила также могут быть написаны в синтаксисе, близком к естественному языку (например, на английском). Это позволяет нетехническим экспертам в области разработки правил с использованием простых английских выражений и нескольких синтаксисов правил Drools, которые не требуют дополнительных технических знаний для понимания. В приведенном ниже примере показано простое правило, написанное в формате DSL. 

Пример правила DSL

Рисунок 2: Файл DSL

Образец файла DSLR

Рисунок 3: Файл DSLR

На рисунках выше у нас есть 2 файла; DSL и файл DSLR. Файл DSL содержит сопоставление условий и последствий, используемых в файле DSLR. Например, условие DSL «Есть клиент с firstName {имя}» сопоставляется с «$ customer: Customer (firstName == {name})». Это отображение / перевод просто говорит движку, как интерпретировать правило, записанное в файле DSLR.

Вывод

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

66
Share: