Deep Dive into EasyRule: Core Module Design Analysis

When business code accumulates many case‑by‑case conditional branches, the resulting if‑else or switch statements become hard to maintain. The author shows a typical pre‑engine snippet with nested conditions and contrasts it with a concise rule‑based representation using EasyRule, demonstrating how the engine separates volatile logic from business code.

The Core project of EasyRule consists of three packages:

annotation : defines rule‑related annotations such as @Action, @Condition, @Fact, @Priority, and @Rule.

api : provides the standard rule interfaces and classes, including Action, Condition, Fact, Facts, Rule, RuleListener, RulesEngine, and Rules. The RulesEngine interface defines the fire method that triggers rule evaluation; custom engines can implement this interface.

core : contains the concrete engine implementation and proxy classes.

Two listener interfaces are highlighted:

RuleListener : allows custom actions at stages such as before rule trigger, after rule trigger, before action execution, after action execution, successful execution, failure, and logical trigger failure.

RulesEngineListener : monitors the overall engine execution, with callbacks before and after the rule engine runs.

The article explains the Fact class (a generic wrapper for a single fact) and the Facts collection (implemented as a Set). Rules stores a set of Rule objects in a TreeSet, ordered by the numeric Priority (lower numbers mean higher priority).

Configuration is handled by RulesEngineParameters, which offers several controls:

priorityThreshold : rules with a priority higher than this value are skipped.

skipOnFirstAppliedRule : stop evaluating further rules after the first successful rule.

skipOnFirstFailedRule : stop after the first rule failure.

skipOnFirstNonTriggeredRule : stop when a rule is not triggered.

These parameters let developers fine‑tune engine behavior for efficiency and predictability.

The Core package’s main classes are the RuleEngine implementation and RuleProxy. The author includes a sequence diagram (image) and a class diagram (image) to illustrate their relationships.

For rule creation without annotations, the RuleBuilder class demonstrates a builder‑pattern approach. The article shows the builder usage code and notes that such a pattern enables storing rule definitions in a database—rules can be loaded at runtime by persisting name, description, condition, and action fields.

Finally, the author summarizes the key parameter effects (skip on first applied/failed/non‑triggered rule and priority threshold) and reiterates that the EasyRule project is a valuable reference for understanding rule‑engine concepts and their practical applications.