Your business rules change faster than your deploy cycles

The Hard-Coded Conditional Trap

Reach into most maturing codebases and the pricing rules sit nowhere in particular. A discount lives in the order controller, an eligibility check hangs off the customer model, a threshold gets duplicated in a service class that someone wrote in a hurry. Ask where that logic lives relative to your data model and the honest answer is a shrug: it has spread across controllers and models until no single person can trace a rule from input to outcome. Each policy becomes a nested if/else, and each branch was added by a different developer under a different deadline. A discount decision three levels deep tends to read like this:

public function discountFor(Order $order, Customer $customer): float
{
    if ($customer->tier === 'gold') {
        if ($order->total > 500) {
            if ($order->placedAt->isWeekend()) {
                return 0.20;
            }
            return 0.15;
        }
        return 0.05;
    }
    return 0.0;
}

The cost is not the line count. It is implicit program flow: the result depends on the order of the branches and a magic 500 buried inside them, none of which is written down anywhere a non-engineer can read. Change that threshold and you might fix one report while quietly breaking another, because nothing declares what else runs through the same path. That is the maintenance danger of scattered rules: every edit is a guess about blast radius, and the guess gets worse as the tree grows.

Code, Configuration, or an Engine: Where the Logic Belongs

Decision logic is not a binary choice between hard-coded logic and a full engine. It sits on a spectrum with three practical tiers, and the usual framing of rules engine vs code skips the tier in the middle where most applications should settle. Before reaching for a decision service, work out which tier your rules genuinely belong in, and what each tier charges you for what it gives back.

Most teams jump straight from tier one to tier three, buying an engine the first time a controller turns ugly. Tier two is usually where they should stop: externalised configuration gives you editable rules and a clean audit trail without a platform to run. Reach for an engine only when an automated process genuinely needs non-developers changing declarative logic themselves, and the rule count keeps climbing past what a config file can hold.

How a Business Rules Engine Works: Facts, Conditions, Actions

Strip away the vendor packaging and a rule has one fixed shape: when <conditions on facts> then <actions>. Facts are the data you feed in, the order, the customer, the basket, held in a working memory the engine calls the fact base. The inference engine takes the whole rule set and tests each rule's conditions against that memory through pattern matching, then fires the actions of every rule that holds. No single rule references another; the engine, not the author, works out what applies.

In practice you rarely author rules one at a time. A decision table is the working representation: input columns on the left, output columns on the right, one row per rule, and a hit policy that resolves what happens when several rows match at once.

Hit policy here is first match: rows are read top to bottom and the first one that fits wins, so a gold customer spending 600 gets 20% and never reaches the lower rows.

That format is not ad hoc. DMN (Decision Model and Notation), the OMG standard, gave decision tables a portable, vendor-neutral definition, with FEEL (Friendly Enough Expression Language) as the syntax inside each cell. It is why a table authored for Camunda DMN reads conceptually the same in GoRules or DecisionRules.

Conflict resolution is the first thing that bites once rule count grows. When two rules fire and disagree, something has to arbitrate: a hit policy on a table, or rule salience assigning explicit priority in a production-rule engine. Get this wrong and the output depends on an evaluation order you never meant to specify.

The Rete algorithm trades memory for speed by caching partial matches so a single fact change does not re-evaluate every rule, though with a few dozen rules that optimisation is irrelevant. Most engines run forward chaining, data-driven from facts toward conclusions; backward chaining, goal-driven from a hypothesis, is rarer and worth knowing exists.

When You Do Not Need One

Most applications never need a rules engine, and reaching for one early is a common form of over-engineering. The question of when to use a rules engine resolves to a single product: rule volatility multiplied by rule count multiplied by who edits them. Fewer than roughly twenty rules that shift a few times a year and are maintained by developers belong in code or a config file. Dozens of interacting rules that change every month and must be adjusted by people outside engineering are where an engine repays its cost. All three factors have to clear together; two out of three is not enough.

The counter-signals matter more, because they describe most codebases.

A distinction worth drawing before you buy: an engine evaluates rules, whereas a business rules management system (BRMS) adds authoring, rule versioning, testing, simulation, deployment and an audit trail on top. Governance, not evaluation speed, is where real deployments tend to succeed or fail.

Building a Lightweight Rule System in Laravel

A small evaluator sitting inside your existing Laravel app captures roughly 80% of the benefit without standing up a second runtime to babysit. This is the shape we reach for when pricing rules, eligibility checks or approval thresholds shift every few weeks: the rules become data the application reads, not branches the application compiles. No Drools, no DMN server, no network hop to a decision service.

Four patterns cover almost every self-built rule system. They are parallel options, not stages, and most projects mix two of them.

For the discount logic from earlier, config-driven rules do the job. Instead of nested conditionals, express the decision table as an ordered list of rules, each pairing a condition with an outcome, and hand it to an evaluator that returns on the first match. The order of the array is the hit policy.

// config/discount_rules.php  (git-versioned, one test per rule)
return [
    // First match wins. Array order is the hit policy.
    ['when' => fn ($o) => $o->tier === 'gold' && $o->total >= 500, 'then' => 0.20],
    ['when' => ['tier',  '=',  'gold'], 'then' => 0.15],
    ['when' => ['total', '>=', 500],    'then' => 0.05],
    ['when' => fn ($o) => true,          'then' => 0.0],
];

class DiscountEvaluator
{
    public function __construct(private array $rules) {}

    public function rate(object $order): float
    {
        foreach ($this->rules as $rule) {
            if ($this->matches($rule['when'], $order)) {
                return $rule['then']; // first hit, no fall-through
            }
        }
        return 0.0;
    }

    private function matches($when, object $order): bool
    {
        if (is_callable($when)) {
            return $when($order);
        }
        [$field, $op, $value] = $when;
        return match ($op) {
            '='   => $order->$field === $value,
            '>='  => $order->$field >= $value,
        };
    }
}

Closures stop scaling once non-developers need to author rules, or the set grows past a couple of dozen. At that point reach for bobthecow/Ruler or Symfony ExpressionLanguage, both of which parse rules written as strings and evaluate them safely, so a predicate can live in a database row rather than a closure.

Govern the self-built version like any other code path. Keep the rules in git-versioned config, write one unit test per rule so a change to the 500 threshold cannot ship untested, and roll changes out staged with a fast rollback. Pair that with an audit trail of who changed a rule and when, so a wrong rate that reaches production can be traced and reverted rather than guessed at.

If You Do Adopt: Matching the Engine to the Problem

If the threshold is genuinely met, the next question is which engine, and the honest answer is that the field splits by weight class rather than by brand. Buying the heaviest option available is the usual mistake. The business rules engine examples that follow map four tiers against the scale of the problem each one suits, from a library you drop into an application you already run to a governed platform built for regulatory audit.

Most readers who reach this table still belong one tier lower than they think: a DMN engine handles problems people reach for Drools to solve, and a library handles problems people reach for DMN to solve. Where an open source rules engine fits, Microsoft RulesEngine, Drools, and GoRules are all free to start with, so the trial cost stays near zero. Either way, the pick belongs inside the wider build versus buy decision rather than sitting apart from it.

Where Your Rules Should Live

Decision logic runs along a spectrum, and most teams should settle at externalised config rather than a full business rules engine. The moving parts (facts, conditions, actions, conflict resolution) are plainer than vendor framing admits. A lightweight Laravel rule set, versioned in git and backed by an audit trail, covers most real requirements without adding another system to operate and monitor.

Reach for a named engine only when volatility, rule count and non-developer editing all cross the line together. Any one of them on its own rarely justifies the cost, and the wrong choice is expensive to unwind.