Я работал с механизмами правил от разных поставщиков (TIBCO, Corticon), и если вы примете их ограничения, они могут быть полезны. Они позволяют бизнесу изменять процессы легко, напрямую, без ИТ, что хорошо и плохо одновременно.
Первая история - это оператор фиксированной связи, который настраивает декомпозицию заказов с помощью таблиц решений. Ни один из коммерческих механизмов правил не предоставил необходимую функциональность, поэтому они создали свои собственные, используя таблицы БД, триггеры и хранимые процедуры. Работает хорошо, но только несколько человек понимают, как - хотя первоначальной идеей было использование таблиц решений, потому что они просты ...
Вторая история - это страховая компания, которая создает онлайн-анкету для сообщения о больничных листах. Это типичное приложение для правил двигателей, до сих пор не удалось. Бизнес был счастлив, что они могут изменить правила, был даже процесс утверждения изменений. Затем механизм правил сгенерировал некоторые классы Java, которые сервер решений мог импортировать без перезапуска. ИТ-отдел отклонил решение, поскольку новый файл Class представляет собой изменение кода, которое должно пройти официальный цикл приемочных испытаний (несколько месяцев + $$$). В результате страховая компания использовала простые таблицы БД и обновления в качестве сценариев SQL.