The Rule Pattern: When Facts Meet Rules

1. The Pain Came First

Everyone knows this. You open a class and there it is: the if-else chain. Twenty branches. Thirty. Some with comments like // TODO: refactor from 2019. You know you shouldn't touch anything — side effects, unknown dependencies, missing tests. So you add your case. At the bottom. After the last else.

And you go home with that bad feeling that you've become part of the problem.

---

2. My First Attempt — And Why It Didn't Make Me Happy

Eventually, I'd had enough. I refactored the if-else chain using an enum pattern:

enum OrderEvent {
    PAY("pay", () -> null),
    SHIP("ship", () -> null);

    final String event;
    final OrderValidator validator;

    OrderEvent(String event, OrderValidator validator) {
      this.event = event;
      this.validator = validator;
    }

    public String getEvent() { return event; }
    public OrderValidator getValidator() { return validator; }


    static OrderEvent fromEvent(String event) {
      for (OrderEvent e : values()) {
          if (e.event.equals(event)) return e;
      }
      throw new IllegalArgumentException("Unknown event: " + event);
    }

}

It worked. But it felt wrong. Too much ceremony. Too much boilerplate for helper methods — getting enum values, setting them, comparing them. An ugly imperative language for something that should be declarative.

---

3. The Realization

Then I understood what I actually wanted: facts and rules. A world where I can say:

"If this condition matches these facts — then do that."

No object hiding behavior. No inheritance hierarchy. No enum tricks. Just one truth: rules check facts. A driver iterates. Done.

This idea has deep roots — Logic Programming languages like Prolog have been built on exactly this foundation for decades: facts, rules, and an inference engine that iterates. But translating that clarity into idiomatic Java — without a framework, without a new language, just records, lambdas, and a stream — that is what this pattern is about.

---

4. The Pattern

// Facts — everything the driver needs to know
// globalCtxt can hold environment data, e.g., the ApplicationContext in Spring
record OrderFacts(String orderId, String event, Object globalCtxt) {}

// A rule: condition + action
record Rule(
    Predicate<OrderFacts> condition,
    Function<OrderFacts, OrderResult> action
) {}

// The rule chain
List<Rule> rules = List.of(
    // Rule: "PAY" event → PaidOrder
    new Rule(
        facts -> facts.event().equals("PAY"),
        facts -> new PaidOrder(facts.orderId())
    ),
    // Rule: "SHIP" event → ShippedOrder
    new Rule(
        facts -> facts.event().equals("SHIP"),
        facts -> new ShippedOrder(facts.orderId())
    )
);

// The driver — stateless, blind, simple
OrderResult resolve(OrderFacts facts) {
    return rules.stream()
        .filter(rule -> rule.condition().test(facts))
        .findFirst()
        .map(rule -> rule.action().apply(facts))
        .orElseGet(() -> new UnknownOrder(facts.orderId()));
}

That's all. No switch. No enum. No inheritance. Just records, lambdas, and a stream.

The order of rules in the list is intentional — findFirst() returns the first match. More specific rules go first, catch-all rules go last. This is not an implementation detail; it is part of the design.

stream().filter().findFirst() is O(n). For typical rule lists this is irrelevant. At scale — hundreds of rules on a hot path — consider grouping rules by a fast discriminator key first.

---

5. Testability — An Underestimated Advantage

With if-else or switch, you always test the entire block. A change in one case can affect all others. With the Rule Pattern, each rule is an independent unit — testable in isolation, without the driver, without context.

// Test a rule in isolation
Rule payRule = new Rule(
    facts -> facts.event().equals("PAY"),
    facts -> new PaidOrder(facts.orderId())
);

assertTrue(payRule.condition().test(new OrderFacts("123", "PAY", null)));
assertFalse(payRule.condition().test(new OrderFacts("123", "SHIP", null)));

// Test the driver in isolation — with arbitrary rules
List<Rule> rules = List.of(payRule);
OrderResult result = resolve(new OrderFacts("123", "PAY", null));
assertInstanceOf(PaidOrder.class, result);

Add a new rule, existing tests stay green — by construction. This isn't a coincidence. It's a direct consequence of the structure: rules are data, not hidden logic inside a class.

---

6. Isolation — The Golden Value

Every rule is an isolated module containing all the logic it needs.
The driver doesn't care what happens inside. It just calls the rule.

This isolation is pure gold:

• Test each rule alone
• Change one rule without touching others
• Handle exceptions locally
• Keep DB and transaction logic visible
• Add new rules without risk

No hidden dependencies. No unexpected side effects. Just isolated, honest modules.

---

7. What the Pattern Replaces

Each GoF pattern solves a real problem — but each brings a cost: an interface to define, classes to implement, a wiring mechanism to maintain. The Rule Pattern collapses all three into one record and a lambda.

No hierarchy. No registration. No casting. Just a condition and an action.

When I saw the pattern in front of me, I realized: many classic GoF patterns are just special cases of this single idea.

Classic Pattern	Rule Pattern Implementation
Strategy	One rule, one factory
Chain of Responsibility	The entire rule list
Observer	Predicate<T> + List<Consumer<U>>
Command	A rule that executes exactly one command
State Machine	Rules + records with invariants

The difference is not what they do — it's what they cost.

---

8. State Machines — The Interesting Case

State machines are the hardest test for any pattern. My solution: Rule Pattern navigates, records enforce.

This first example shows a hybrid approach: sealed defines the structure and enforces invariants at compile time — the Rule Pattern handles the navigation.

Section 10 shows what happens when you drop the sealed interface entirely.

sealed interface OrderState permits NewOrder, ActiveOrder, CancelledOrder {}

record NewOrder(Order order) implements OrderState {
    public ActiveOrder activate() {
        return new ActiveOrder(order, LocalDateTime.now());
    }
    public CancelledOrder cancel() {
        return new CancelledOrder(order, LocalDateTime.now(), "before activation");
    }
}

record ActiveOrder(Order order, LocalDateTime activatedAt) implements OrderState {
    public CancelledOrder cancel() {
        return new CancelledOrder(order, LocalDateTime.now(), "after activation");
    }
    // activate() does not exist here — an impossible transition is simply absent
}

record CancelledOrder(Order order, LocalDateTime cancelledAt, String reason) implements OrderState {
    // no methods — end of the line
}

The record enforces the invariant structurally — cancelledAt is always set, always valid. No null. No invalid state possible.

The Rule Pattern handles navigation:

record OrderFacts(OrderState state, String event) {}

record OrderRule(
    Predicate<OrderFacts> condition,
    Function<OrderFacts, OrderState> action
) {}

List<OrderRule> rules = List.of(
    new OrderRule(
        facts -> facts.state() instanceof NewOrder && facts.event().equals("ACTIVATE"),
        facts -> ((NewOrder) facts.state()).activate()
    ),
    new OrderRule(
        facts -> facts.state() instanceof NewOrder && facts.event().equals("CANCEL"),
        facts -> ((NewOrder) facts.state()).cancel()
    ),
    new OrderRule(
        facts -> facts.state() instanceof ActiveOrder && facts.event().equals("CANCEL"),
        facts -> ((ActiveOrder) facts.state()).cancel()
    )
);

OrderState next = rules.stream()
    .filter(r -> r.condition().test(facts))
    .findFirst()
    .map(r -> r.action().apply(facts))
    .orElse(facts.state());

Two clear responsibilities:

• Which transition is allowed? → Rule Pattern
• What happens during the transition? → Record with its methods and invariants

---

9. Observer — Even More Elegant

record ObserverRule<T, U>(
    Predicate<T> condition,
    List<Consumer<U>> actions
) {}

List<ObserverRule<Event, Payload>> rules = List.of(
    new ObserverRule<>(
        event -> event.type().equals("ORDER_PLACED"),
        List.of(
            payload -> notificationService.send(payload),
            payload -> inventoryService.reserve(payload),
            payload -> auditLog.record(payload)
        )
    )
);

// Driver — with flatMap
void notify(Event event, Payload payload) {
    rules.stream()
        .filter(rule -> rule.condition().test(event))
        .flatMap(rule -> rule.actions().stream())
        .forEach(action -> action.accept(payload));
}

One event, one or more matching rules, each with its own list of actions. Adding a new subscriber = one new rule or one new line in an existing rule's action list. No interface, no addListener(), no casting.

---

10. Comparison: DOP vs. Rule Pattern — Same Domain, Two Approaches

There's a lot of well-deserved discussion about Data-Oriented Programming (DOP) in the Java community right now. Sealed types and pattern matching are making Java incredibly expressive. Let's see what happens when we take this idea of data separation to its logical conclusion — and even drop the sealed interface.

The Classic DOP Approach (Safety Through Structure)

DOP leverages compiler safety:

sealed interface OrderState permits NewOrder, ActiveOrder, CancelledOrder {}

This is fantastic when your domain is closed and the states are absolutely finite. The compiler warns you when you forget a case in a switch. That's a real safety net. But it comes at a price: the switch block must know every state and every method by name. When a new state arrives, we have to modify the switch block.

DOP — sealed types + pattern matching:

sealed interface OrderState permits NewOrder, ActiveOrder, CancelledOrder {}

record NewOrder(Order order) implements OrderState {}
record ActiveOrder(Order order, LocalDateTime activatedAt) implements OrderState {}
record CancelledOrder(Order order, LocalDateTime cancelledAt) implements OrderState {}

OrderState process(OrderState state, String event) {
    return switch (state) {
        case NewOrder n when event.equals("ACTIVATE") ->
            new ActiveOrder(n.order(), LocalDateTime.now());
        case NewOrder n when event.equals("CANCEL") ->
            new CancelledOrder(n.order(), LocalDateTime.now());
        case ActiveOrder a when event.equals("CANCEL") ->
            new CancelledOrder(a.order(), LocalDateTime.now());
        default -> state;
    };
}

Clean. Compiler-exhaustive. If you forget a case, you get a warning.

The Rule Pattern Without Sealed Interface (The Freedom of Data):

What happens when we completely decouple the records and treat the state as a universal Object?

record NewOrder(Order order) {
    public ActiveOrder activate() { return new ActiveOrder(order, LocalDateTime.now()); }
    public CancelledOrder cancel() { return new CancelledOrder(order, LocalDateTime.now()); }
}
record ActiveOrder(Order order, LocalDateTime activatedAt) {
    public CancelledOrder cancel() { return new CancelledOrder(order, LocalDateTime.now()); }
}
record CancelledOrder(Order order, LocalDateTime cancelledAt) {}

record OrderFacts(Object state, String event) {}

record FailedOrder(OrderFacts facts, Exception cause) {}

record OrderRule(
    Predicate<OrderFacts> condition,
    Function<OrderFacts, Object> action // intentionally untyped — see below
) {}

List<OrderRule> rules = List.of(
    new OrderRule(
        f -> f.state() instanceof NewOrder && f.event().equals("ACTIVATE"),
        f -> {
            try {
                return ((NewOrder) f.state()).activate();
            } catch (Exception e) { // Same exception handling can be applied to any rule
                return new FailedOrder(f,e); 
            }
        }
    ),
    new OrderRule(
        f -> f.state() instanceof NewOrder && f.event().equals("CANCEL"),
        f -> ((NewOrder) f.state()).cancel()
    ),
    new OrderRule(
        f -> f.state() instanceof ActiveOrder && f.event().equals("CANCEL"),
        f -> ((ActiveOrder) f.state()).cancel()
    )
);

Object next = rules.stream()
    .filter(r -> r.condition().test(facts))
    .findFirst()
    .map(r -> r.action().apply(facts))
    .orElse(facts.state());

The return type is deliberately Object. This is the trade-off: we gain full openness — no interface, no hierarchy — and we lose compile-time type safety on the result. A clear default case and tests compensate for that.

What is the real difference?

Even when we optimize the DOP example and move the logic into the records (so that the case only calls n.activate()), one fundamental problem remains: the switch block must know every method and every state by name. It is hard-wired.

When a new state like InReturn with a returnOrder() method arrives tomorrow, the compiler's exhaustiveness check fails. We have no choice — the switch block must be extended.

With the Rule Pattern, however, the driver is completely ignorant. It's just an assembly line worker. For the new state, we simply add a new, isolated rule to the list. Neither the driver nor the existing rules need to be touched. That's the pure essence of KISS: extending by simply adding data, without endangering existing code.

Feature	DOP (sealed + pattern matching)	Rule Pattern (without interface)
Focus	Maximum compile-time safety	Maximum extensibility
Artificial hierarchy	Yes (implements OrderState required)	No (completely free records)
Code coupling	High (switch must know every type)	Null (driver sees only Object)
Compile-time exhaustiveness	✓ Compiler warns about missing cases	✗ Only at runtime
New rule / state	Open switch, add new case	One line in the list
Load rules from configuration	Not possible	Possible
Complex conditions	Switch becomes messy	Predicate arbitrarily composable
Exception handling	Centralized (switch catches all)	Isolated per rule (each rule can handle differently)

---

11. Counterarguments — And My Honest Answers

"This isn't readable."

Readability is a matter of habit. Anyone who works with streams and records will quickly feel comfortable with this.

"No compile-time exhaustiveness — you only notice missing cases at runtime."

True. That's the conscious trade-off: I exchange compile-time safety for openness and simplicity. A good default case and tests compensate for this.

"What about frameworks — Spring, Hibernate?"

At the boundaries, I build adapters. The core of my application doesn't depend on heavy frameworks – that makes it easier to test, reason about, and change. The Rule Pattern describes the domain logic; it doesn't know anything about Spring. You can keep it as a property in a service and let the DI framework inject whatever is needed. That keeps the pattern pure and the integration clean.

If a rule genuinely needs framework services, pass them explicitly through the facts record as a typed context — not as Object globalCtxt, but as a dedicated record:

record RuleContext(EmailService email, OrderRepository repo) {}
record OrderFacts(OrderState state, String event, RuleContext ctx) {}

The Spring @Service builds the RuleContext and passes it in. The domain layer has no Spring annotations — rules stay testable with new RuleContext(mockEmail, mockRepo). Everything flows through facts.

"But invariants? Your entities aren't safe anymore!"

My states are records — immutable by default. Each state handles its own invariants. That's even cleaner than classic OOP.

"What about performance"

No proxies. No bytecode weaving. No reflection at runtime. A rule is a plain record — two function references, nothing more. The driver is a stream call. That is as close to raw Java as it gets.

---

12. Conclusion

The Rule Pattern is not a revolution. It's a quiet extension — three simple ideas:

• Record → Facts are structure, invariants built-in
• Rule → Condition + result, declarative
• Driver → Stateless, blind, only iterates

Perhaps we don't need less OOP in Java. But sometimes, records, functional interfaces, and one simple idea are enough — rules that meet facts.

I'm still looking for real counterarguments. If you see something I've missed — tell me. Really. I don't want to be right. I want to know if this pattern delivers what it promises.

Or whether we in the Java world have sometimes simply forgotten how elegant and maintainable software can be when we stop thinking in rigid hierarchies and start treating logic as what it really is: rules that meet facts.