DMN таблицы решений: формализация бизнес-правил без программистов

Decision Model and Notation (DMN) — относительно молодой стандарт OMG (2015), который часто остаётся в тени своего «старшего брата» BPMN. Однако в проектах автоматизации DMN оказывается не менее важным инструментом, чем BPMN.

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

Долгое время бизнес-логика встраивалась прямо в BPMN-диаграммы через XOR-шлюзы с многочисленными ветками. Когда правил становилось больше десятка, диаграммы превращались в нечитаемые джунгли. К тому же изменение правил требовало изменения диаграммы процесса, что приводило к ненужной связности.

DMN решает эту проблему, отделяя логику решения от логики процесса. BPMN-задача типа Business Rule Task ссылается на DMN-модель, которая может изменяться независимо.

Два уровня DMN

DMN имеет два уровня абстракции:

DRD (Decision Requirements Diagram)

DRD — это граф зависимостей между решениями. Каждый узел графа — отдельное решение, требующее определённых входных данных. Решения могут зависеть друг от друга, образуя иерархию.

Например, в задаче оценки кредитной заявки:

«Одобрить кредит» зависит от «Скоринг» и «Проверка дохода»
«Скоринг» зависит от «История погашений» и «Кредитная нагрузка»
«Проверка дохода» зависит от «Тип занятости» и «Подтверждённый доход»

Decision Tables

Decision Tables реализуют конкретную логику решений. Каждая строка таблицы — правило. Каждая колонка слева — входная переменная, справа — выходное значение.

Пример таблицы для решения «Скоринг»:

История погашений	Кредитная нагрузка	Возраст	Балл скоринга
Отличная	< 30%	> 25	95
Отличная	< 30%	≤ 25	80
Хорошая	< 50%	> 25	75
Хорошая	< 50%	≤ 25	60
Средняя	< 70%	-	45
Плохая	-	-	20

Политики срабатывания (Hit Policies)

DMN определяет несколько политик того, как обрабатываются ситуации, когда правилу соответствует несколько строк таблицы:

Unique (U) — должна сработать ровно одна строка, иначе ошибка
Any (A) — несколько строк могут сработать, но все должны давать одинаковый результат
First (F) — срабатывает первая подходящая строка (порядок важен)
Priority (P) — применяется правило с наивысшим приоритетом
Collect (C) — собирается список всех результатов

Выбор политики существенно влияет на семантику. Большинство практиков рекомендуют использовать Unique там, где это возможно — это даёт максимальную предсказуемость.

FEEL — язык выражений

DMN включает специально разработанный язык выражений FEEL (Friendly Enough Expression Language). Его задача — позволить аналитикам записывать сложные правила в форме, понятной человеку, но строго формализованной для компьютера.

Примеры FEEL-выражений:

[100..500]        // диапазон 100-500 включительно
> 18              // больше 18
not("Москва")     // не равно "Москва"
in ("RU", "BY")   // одно из значений
date("2025-01-15")

FEEL поддерживает арифметику, логику, работу со строками, датами, списками, контекстами. Это не язык программирования общего назначения, а специализированный декларативный язык для бизнес-правил.

Где применяется DMN

Типичные сценарии:

Кредитный скоринг — расчёт балла и решение об одобрении
Страховые тарифы — расчёт стоимости полиса с учётом параметров клиента
Маршрутизация заявок — определение оператора для обработки
Конфигурация продуктов — допустимые комбинации параметров
Расчёт скидок — применение акций и бонусных программ

Платформы

DMN поддерживается в основных BPM-движках: Camunda DMN, IBM ODM, Drools, Trisotech, Signavio. Некоторые из них предоставляют визуальные редакторы решений для бизнес-аналитиков.

Ограничения

DMN не подходит для машинного обучения и нечёткой логики
Сложные многомерные правила в табличном виде становятся громоздкими
Стандарт менее известен, чем BPMN, что усложняет поиск специалистов

Заключение

DMN — мощный инструмент, недостаточно используемый в российской практике. Внедрение DMN рядом с BPMN позволяет существенно упростить процессные модели и дать бизнес-аналитикам прямой контроль над логикой решений без обращения к разработчикам.