Вступление.
Разрабатывая одно из бизнес-приложений для нашей компании, я столкнулся с проблемой формализации бизнес правил которые должно реализовывать приложение. Хорошим подходом для реализации бизнес правил, возможно, может выступать паттерн "Стратегия" [Strategy]. Однако, как только правила меняются либо последовательность действий для достижения цели должна поменяться, а может и то и другое, нужно переписывать стратегию либо писать новую. Это не всегда удобно, особенно в часто меняющейся бизнес логике (а она часто меняется в активно растущих компаниях).
Что для меня стратегия? Стратегия это набор сервисов которые последовательно применяются к бизнес - объектам, либо объектам вашей предметной логики. Сервисы меняют состояния ваших объектов, и таким образом от сервиса к сервису вы получаете необходимый результат.
К чему я стремлюсь? Стремления мои были нацелены к тому чтобы настройка стратегий была гибкой, то есть для того, чтобы изменить стратегию мне необходимо было бы просто поменять "связи" между сервисами или "нарастить" стратегию очередными сервисами, самое крайнее - это дописать новый сервис и включить в стратегию. Одним из требований, которым я руководствовался - это манипулируя набором сервисов собирать новые стратегии с минимальным, а лучше нулевым изменением кода.
jBoss jBPM
Не секрет что java технологии бурно развиваются, и область граф - ориентированного программирования тоже не стоит на месте. Технология с которой я познакомился называется BPM (Business Process Modeling). И её реализацией jBoss jBPM.
jBoss jBPM позволяет:
- Моделировать бизнес процессы до момента их реализации.
- Поддерживает язык PDL (Process Definition Language) - XML-based описание бизнес процессов
- Система логирования ваших бизнес процессов
- Сохранение состояний ваших бизнес объектов и определений процессов в БД и чтение из неё.
- Поддержка транзакций в бизнес процессах.
- Обработка исключений.
Основными элементами BPM являются узлы (Nodes) и переходы (transitions). Каждый узел связан с каким то событием в вашем бизнес процессе. Переходы - это связи между узлами процесса.
Хорошим подходом в моделировании бизнес процессов, я считаю, является моделирование графа. Граф можно и нужно моделировать до реализации, зачастую с заказчиком системы, чтобы ясно представлять что за каждым узлом должно скрываться.
Каким же образом к графу "цеплять" java-код реализующий логику бизнес-процессов? Для этого есть действия (Action). Действия можно разделить на 2 типа - действия привязанные к узлам (node) и действия привязанные к событиям (events), например события "вход в узел" или "выход из него" во отличии действий по событию действия привязанные к узлам могут влиять на процесс перехода к другим узлам.
Каждому действию (Action) соответствует обработчик (ActionHandler) в котором реализована логика.
Вот список типов узлов (Node).
- task-node - содержит перечень задач которые необходимо выполнить при входе в данный узел
- State - узел ожидающий определенного состояния. Никаких задач в нем не выполняется
- Decision - узел принятия решения - по какому переходу дальше двигаться
- Fork - разветвляет граф на конкурентные потоки выполнения.
- Join - собирает разветвленные потоки. Каждому Fork должен соответствовать свой join узел.
- Node - самый часто используемый тип узла - используется для внедрения вашего года в граф выполнения.
jBoss jBPM содержит еще много "вкусных вещей" - актеры и их роли, Swimlane, планировщики задач, асинхронное выполнение, бизнес календарь.
