Я бы использовал WF или Drools, если вы пытаетесь создать абстракцию, с которой могли бы работать непрограммисты для разработки бизнес-правил. Однако, если вы имеете дело с программистами, то абстракция WF не стоит времени, необходимого для разработки решения, я не вижу дополнительной ценности ваших инвестиций.
База данных — хороший способ поддерживать правила, которые могут сильно измениться, но позвольте мне предложить возможную альтернативу (не обязательно лучшую, но альтернативу).
1) Выделите бизнес-логику на отдельный уровень (dll) - абстрагируйте то, как вы ее вызываете, с некоторыми интерфейсами (посмотрите на шаблоны стратегии и наблюдателя), т.е. IRuleEvaluator.Evaluate(string myParams).
2) Теперь вы можете создавать отдельные классы для каждого правила (при необходимости) и сопутствующие модульные тесты.
3) Теперь самое главное: подключите все, что находится за кулисами, в контейнере IOC — dll и сам экземпляр оценщика правил. Таким образом, ваш оценщик правил строится на основе конфигурации во время выполнения — ничто не жестко запрограммировано вместе.
Этот подход очень динамичен (может быть, слишком динамичен на некоторые вкусы) — он позволит вам иметь фактические дискретные модульные тесты для всех ваших правил. Если вам нужно повторно развернуть или изменить правило, вы можете удалить новую DLL, изменить файл конфигурации IOC, перезапустить и проверить или отменить изменение, если что-то не так, без изменения основного кода (так же, как база данных). И в отличие от базы данных, она будет держать логику и код приложения под одним зонтиком, вместо того, чтобы наполовину писаться на C# и наполовину на SQL.
Прикрепляю к посту несколько видео по теме: