Движок бизнес-правил: DSL/JSON, интерпретатор и трассировка

1.

Тема призентации:
Создание модуля «Движок бизнес-правил» (DSL/JSON) с
интерпретатором, приоритетами правил и трассировкой
исполнения.

2. Зачем нужен Движок бизнес-правил?

• Проблема: Бизнес-логика («скидки», «акции», «проверки») часто «зашита» в код.
Любое изменение требует усилий разработчиков и долгого деплоя.
• Решение: Выносим логику в правила, которые можно менять на лету, без перезапуска
системы.
• Цель проекта: Создать гибкий инструмент для управления логикой приложений
силами аналитиков или через внешние системы.

3. Концепция: DSL и JSON

• DSL (Domain Specific Language): Специализированный «почти английский» язык
для описания условий.
(Пример: IF order.total > 1000 THEN apply 10% discount). Удобен для чтения.
• JSON: Универсальный формат для хранения и передачи правил между сервисами.
Легко парсится и генерируется.
• Связка: Мы пишем правила на понятном DSL, а система хранит и
интерпретирует их как JSON-структуры.

4. Интерпретатор и Трассировка

(Почему сработало?)
• Интерпретатор: «Мозг» системы. Читает JSON-правило, подставляет входящие
данные (контекст заказа/пользователя) и вычисляет результат (true/false).
• Трассировка (Tracing): Ключевая функция для отладки. Система записывает
«след»:
Какое правило проверялось?
Какие условия сработали, а какие нет?
Почему было применено именно это правило?

5. Приоритеты Правил (Chain of Responsibility)

Зачем нужны: Правила могут конфликтовать (одно дает скидку 5%, другое —
10%).
Решение: У каждого правила есть числовой приоритет (1, 100, 1000).
Логика работы:
Система сортирует правила по приоритету (от высшего к низшему).
Проходит по цепочке.
Останавливается при первом сработавшем правиле (стратегия First Match) или
выполняет все (стратегия Accumulate).

6. Архитектура решения

Архитектура решения (Как это работает)
1. Хранилище: Правила (DSL/JSON) лежат в БД или Git.
2. Загрузчик: Подтягивает правила в кэш приложения.
3. Ядро (Engine): Получает входные данные (объект запроса).
4. Выполнение: Ядро сортирует правила по приоритету, прогоняет их через
интерпретатор и собирает результаты + трассировку.
5. Ответ: Клиент получает не только результат, но и лог (трассировку) того, как
было принято решение.

7. Что дает такой подход? (Итоги)

• Гибкость: Изменение логики за 5 минут правкой JSON-файла.
• Прозрачность: Трассировка отвечает на вопрос «Почему сработало именно
так?» — важно для аудита и поддержки.
• Масштабируемость: Легко добавлять новые правила, не трогая старый код.
• Разделение ответственности: Бизнес управляет правилами, разработчики
управляют производительностью движка.