Rule Engine

Implementations

Business leaders with subject matter expertise can define and manage their own logic, independent of engineering.

some important caveats with rules engines in general:

Need to be able to resolve conflicting rules in the engine itself - looks like RulesEngine does not natively handle this (not surprised, that's domain-specific.) You need an input validation layer that tells the user that their rule is invalid because it will never produce a successful result.
Persisting rule state - if you have long-running workflows, i.e. the type that is common with event-sourcing, you have one of two methods for executing domain events against a rules engine: 1. replay all events against the rules engine each time a new event is received or 2. persist the "completion state" of each rule each time an event is persisted, and recover that as a separate snapshot. The challenge with the second approach is how you handle updating a rules set - we were able to invalidate individual rules using a hash signature while preserving the output values of rules that were unchanged.
Adding new rulesets on the fly - if you want the ability to dynamically create new campaigns, you have to decide how you want to handle historical data. In our case, since we were a high volume streaming operation, our choice was to not retroactively apply older events when new rules were added as this would create a "thundering herd" problem for us. We only applied new rules to entities that processed new events after the additional rule-based campaigns were defined.

Workflow Engine	Business Engine
Based on process	Based on rules
Specific to a workflow	Enterprise specific
A program designed to run workflow instances based on the process model	A program designed to help with complex decision-making
Inherent driving force in an automated workflow	Works as a pluggable element that could be separated from the application code
Help with carrying out a business process	Help with creating business knowledge

Children