Разработка правил и управление развертыванием с помощью Drools Guvnor

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

После первого запуска делайте выпуски инкрементными и небольшими

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

Ваше приложение запущено, и ваши бизнес-пользователи поддерживают правила в таблицах решений. Вы добились больших успехов в том, что люди в отрасли называют «гибкостью бизнеса». К сожалению, это, как правило, происходит за счет гибкости разработки приложений. Все ваши правила управляемого редактора и правила таблиц решений привязаны к вашей модели фактов, поэтому любые изменения существующих свойств этой модели фактов нарушат ваши таблицы решений. В отличие от большинства современных IDE, вы не можете просто щелкнуть правой кнопкой мыши метод getX () факта, переименовать его и ожидать, что весь код, который полагается на это свойство, будет обновлен.

Таблицы решений и управляемые правила сложно реорганизовать. Если факт был переименован, то во многих (всех?) Версиях Guvnor это правило / таблица больше не открывается. Вам необходимо получить доступ к базовому XML-файлу через WebDav и выполнить некоторый текстовый поиск и замену. Это может быть очень сложно, учитывая, что для этого вам необходимо загрузить файл из производственной среды в тестовую среду, внести изменения, протестировать их, развернуть в тестовой среде. Когда вы довольны своими изменениями, вам нужно отправить их обратно на «производственный» Хозяин. К сожалению, пока вы это делали, пользователи обновили несколько таблиц решений, и вам нужно либо начать заново, либо повторно применить изменения, внесенные за последние пару дней. В идеальном мире ваши бизнес-пользователи согласятся не вносить изменения в правила в течение определенного периода времени. Но единственный способ сделать это возможным - сделать изменения небольшими, чтобы вы могли внести их за пару часов или день, в зависимости от того, насколько великодушны они.

Чтобы смягчить это:

1. Храните факты, используемые в Guvnor, отдельно от классов домена вашего приложения. Затем разработчики ваших приложений могут провести рефакторинг внутренней модели приложения по своему усмотрению, но такие изменения не повлияют на бизнес-модель. Поддерживайте сопоставления между ними и убедитесь, что существуют тесты, охватывающие эти сопоставления.
2. Избегайте таких изменений, как переименование фактов или их свойств. Убедитесь, что создаваемые вами факты и их свойства имеют имена, подходящие для домена, и согласовывают их с бизнесом. С другой стороны, добавление нового свойства относительно безболезненно. Стоит побудить пользователей взглянуть на свои планы на будущее.
3. Делайте факты как можно проще. Не усложняйте пары «имя-значение», если в этом нет необходимости. Во-первых, вашим бизнес-пользователям будет намного проще поддерживать правила. Ваш приоритет в отношении всего, что управляется внутри Guvnor, всегда должен заключаться в упрощении обслуживания бизнес-пользователями.
4. Не допускайте внешних зависимостей в ваших фактах. Разработчик может подумать, что аннотировать факт как JPA @Entity - это хорошая идея для облегчения сохранения. К сожалению, это добавляет зависимости, которые необходимо добавить в путь к классам Guvnor, что требует перезапуска.

Советы и приемы

Мой личный метод внесения изменений в среду - это подключить Eclipse к двум каталогам Guvnor WebDav и проверить правила в локальных каталогах, где каждый локальный каталог сопоставляется со средой. Затем я использую инструменты Eclipse diff.

При создании базы знаний, управляемой Guvnor, я создаю отдельный проект Maven, содержащий только факты и не зависящий от чего-либо еще. Так будет намного проще содержать их в чистоте. Кроме того, когда мне действительно нужно добавить зависимость (например, я использую JodaTime, где это возможно), тогда в сборке может быть шаг для создания закрашенного JAR, содержащего все зависимости. Таким образом, вы когда-либо развертываете в Guvnor только один JAR, который гарантированно будет содержать правильные версии ваших зависимостей.

Я уверен, что я придумаю еще кое-что. Я постараюсь не забыть вернуться к этому ...