Нет ничего плохого в том, что бизнес-логика c абстрактна. И декларативные правила кажутся подходящими в вашем сценарии. Нужно уметь извлекать отчет, читаемый человеком, с указанием бизнес-логики c, применяемых правил.
Таким образом, на первом этапе будут требования, которые вы хотели бы видеть в качестве продукта. Это может стать дополнительным кодом / моделированием без ущерба для существующей кодовой базы.
Не начинать с дикой природы: не искать библиотеку решений, когда проблема и решение неясны. Часто применяется «структура решения», и проблема моделируется после этого. С большим количеством кода котельной пластины и не совсем совпадающим с тем, что вы на самом деле хотели бы.
На этом этапе вы, вероятно, могли бы создать простой прототип механизма правил "сделай сам". Может быть, даже сделать быстрый и грубый прототип. Затем найдите существующие механизмы правил и создайте прототипы. Желательно не в вашем приложении, а с использованием Test-Driven-Development в юнит-тестах.
Плохая идея - немедленно оставить обслуживание определения правил конечным пользователям-администраторам. Такая функциональность имеет значение: отсутствие подготовки к тестированию, работа в производственной системе, управление версиями, техническая квалификация конечных пользователей, например, большая интегративная картина.
В заключение: это могло быть чем-то для разработки программного обеспечения форум.