DMN и бизнес-правила для «чайников»

DMN — это набор значков и их определений в XML. С помощью этих значков можно описывать решения, принимаемые бизнесом. Что за значки, что такое решение и какое вам до этого всего дело — читайте в этой статье.

DMN — удобная нотация для правил

DMN можно использовать, чтобы явно описывать из каких соображений принимаются решения. Как и в BPMN (который можно начать учить по моей бесплатной рассылке), DMN имеет 2 способа применения:

• Аналитический — когда мы просто составляем таблички решений в наших программах, а разработчики их программируют..
• Автоматизационный — когда наши таблички исполняются DMN-движком в том виде, в в котором нарисованы. В таком случае у нас минимальный риск, что разработчики что-то не так поняли в ТЗ.

DMN придумали в 2015 году те же ребята, что и BPMN — эти 2 нотации отлично сочетаются друг с другом. Но можно использовать и отдельно.

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

DMN — это таблица

В терминах DMN решение — это таблица.

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

Решение состоит из:

• Название.
• Метод срабатывания (hit policy). Если там стоит U, то значит у нас политика срабатывания — unique. Т.е. решение должно всегда отдавать одно, уникальное решение (пересечение не допускается). Есть несколько вариантов.
• Входные переменные.
• Выходные данные — для каждой возможной входящей записи мы определяем выходную переменную. 
• Правило — это набор входных и выходных данных, строка таблицы. У каждого правила есть номер, он указан в таблице слева.
• Аннотация — это текст справа, он используется для объяснения правила и не автоматизируется.

Несколько условий в DMN

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

В этом примере мы хотим проверить, если среди гостей вегетарианцы. Несмотря на время года, мы всегда должны готовить пасту для вегетарианцев. Правило №5 имеет «-» во входных значениях времени года. Это значит, что несмотря на время года, если среди гостей вегетарианцы, то мы готовим пасту.

Комбинация входных параметров в правиле всегда работает по логике И.

Язык FEEL для работы с входными данными

В DMN встроен FEEL (Friendly Enough Expression Language). Это специальный “язык” для проверки выражений на входных данных. Эти проверки выполняются до правил.

С помощью FEEL можно:

• Проверить строку
• Проверить булеву переменную
• Вхождение числа в интервал
• Дату (в прошлом или будущем)
• И еще много всего

В первую очередь, вы увидите серые строки. Эти строки описывают технические детали, которые нужны движку (в моём случае Camunda) для выполнения решения.  Первая строка описывает название переменной. Вторая — тип переменной, возвращаемой из выражения. Это важно, чтобы понимать, какие FEEL выражения можно применять к входных переменным.

Выражений FEEL достаточно, чтобы полноценно работать со входными переменными, не прибегая к коду:

DMN и BPMN

BPMN без бизнес-правил может выглядеть так:

А с DMN может выглядеть так:

С помощью решений можно значительно улучшить ваши BPMN-схемы.  

Поиграться руками

Как работают правила на практике, вы можете посмотреть по этой ссылке. Напишите в комментарии — имеет ли право на жизнь DMN в вашей практике? Использовали ли уже? Или используете другой подход?