Reader: explicit environments

Policy code needs configuration — the income threshold, the minimum age, the rule version stamp that goes on every audit record. The usual Java answer is dependency injection at the class level or, worse, a static config holder reached from anywhere. Reader<R, A> makes the dependency a parameter of the computation: it is a function R → A wearing a wrapper that composes.

The implementation

1
public record Reader<R, A>(Fn1<R, A> run) {
2

3
    public A apply(R environment) {
4
        return run.apply(environment);
5
    }
6

7
    public <B> Reader<R, B> map(Fn1<? super A, ? extends B> mapper) {
8
        return new Reader<>(environment -> mapper.apply(run.apply(environment)));
9
    }
10

11
    public <B> Reader<R, B> flatMap(Fn1<? super A, ? extends Reader<R, B>> mapper) {
12
        return new Reader<>(environment -> mapper.apply(run.apply(environment)).apply(environment));
13
    }
14

15
    public static <R, A> Reader<R, A> of(A value) {
16
        return new Reader<>(environment -> value);
17
    }
18

19
    public static <R> Reader<R, R> ask() {
20
        return new Reader<>(environment -> environment);
21
    }
22
}

ask returns the environment itself — the primitive from which every other read is built by map. flatMap lets one computation choose the next read based on a previous result; note that both get the same environment.

Scheme example: policy reads

1
public static Reader<PolicyEnvironment, Long> incomeThreshold() {
2
    return Reader.<PolicyEnvironment>ask().map(PolicyEnvironment::incomeThreshold);
3
}
4

5
public static Reader<PolicyEnvironment, Boolean> incomeWithinLimit(long income) {
6
    return incomeThreshold().map(limit -> income <= limit);
7
}
8

9
public static Reader<PolicyEnvironment, String> stampedOutcome(String citizenId) {
10
    return Reader.<PolicyEnvironment>ask()
11
            .map(environment -> citizenId + " evaluated under rules " + environment.ruleVersion());
12
}

1
PolicyEnvironment rules = new PolicyEnvironment(300_000L, 18, "farmer-support-2026.1");
2

3
boolean ok = PolicyQueries.incomeWithinLimit(120_000).apply(rules);   // true
4
String stamp = PolicyQueries.stampedOutcome("C-1").apply(rules);
5
// "C-1 evaluated under rules farmer-support-2026.1"

Every computation declares its environment in its type. The rule version that ends up on the audit record cannot come from a mutable global — it came through ask, which means the same call with the same environment always produces the same stamp. That is what reproducible decisions require.

Reader versus dependency injection

This is the comparison that matters in Spring Boot code, so be precise: Reader and constructor injection solve the same problem — “this computation needs config” — at different granularities. Injection binds the dependency when the object is built; Reader binds it when the computation runs. Use Reader when the same computation must run against different environments within one object graph — per-request rule versions, A/B thresholds, tenant configs. If your environment is fixed per service instance, ordinary constructor injection is simpler and already understood by everyone on the team; Reader is the tool for when the environment genuinely varies per call.