4.3 Algebraic Abstraction and Side Effects: From Monoid to Monad

Ah Hua combines a sequence of business steps, only to find that exceptions, logs, and asynchronous states nest inside one another. She wonders which combination patterns can be expressed through types.

Monoid, Functor, and Monad are often presented as metaphors, resulting in learners remembering only "boxes" and "pipes," without understanding the specific operations they constrain. A more reliable approach is to examine three questions: what values are available, which combinations are permitted, and what laws must those combinations satisfy.

Monoid: The Smallest Structure That Can Be Parallelized

A Monoid is composed of the following:

• A set of values;
• A binary combination operation combine(a, b);
• A unit element empty;
• The combination operation satisfies the associative law.

combine(combine(a, b), c) = combine(a, combine(b, c))
combine(empty, a) = a
combine(a, empty) = a

Examples include:

Value	Combination Operation	Unit Element
Integers	Addition	0
Integers	Multiplication	1
Strings	Concatenation	""
Lists	List concatenation	Empty list
Sets	Union	Empty set

The same type of value can support multiple Monoids. For instance, integer addition and multiplication have different unit elements, so saying "integers form a Monoid" is incomplete, it must specify the combination operation.

The associative law enables systems to split data into chunks, aggregate locally, and then merge results:

Chunk A ──sum──┐
Chunk B ──sum──┼──sum──> Total sum
Chunk C ──sum──┘

This is the foundational principle behind parallel reduction, MapReduce, and distributed metric aggregation. If the operation does not satisfy associativity, changing the order of chunking can lead to different results.

Functor: Mapping in Context

Applying a regular function A -> B to a context F<A> yields F<B>, typically written as map:

map : (A -> B) -> F<A> -> F<B>

Java Optional.map demonstrates this pattern:

Optional<User> user = repository.findUser(id);
Optional<String> email = user.map(User::email);

The mapping transforms the internal value while preserving the "possibly absent value" context. To remain predictable, map must satisfy two core laws:

map(identity) = identity
map(f then g) = map(f) then map(g)

These laws have practical meaning: inserting an identity mapping during refactoring should not alter behavior; composing or splitting consecutive mappings should not change the outcome. If map secretly makes database calls or alters dependency invocation counts, these equivalence transformations will break.

Applicative: Combining Independent Contextual Computations

Suppose creating a user requires validating both name and email, and you want to return all errors in a single response:

Validated<Name>  +  Validated<Email>
             ↓ Combine
       Validated<User>

Since the validations are independent, they can be executed separately, and their successful results passed to a constructor. On failure, errors are accumulated. The Applicative abstraction precisely describes this pattern, where the structure is known in advance and the computations are independent of one another.

It differs from the next section in that the second computation does not depend on the value produced by the first.

Monad: Making the Next Step Depend on the Previous Value

The core operations of a monad can be expressed as:

pure    : A -> M<A>
flatMap : M<A> -> (A -> M<B>) -> M<B>

For example, after retrieving a user, you must obtain the user's organization ID before knowing which organization to query next:

Optional<Organization> organization =
    repository.findUser(userId)
        .flatMap(user -> repository.findOrganization(user.organizationId()));

If the user does not exist, subsequent queries are skipped; if the user exists, the function returns a new Optional<Organization>, flatMap avoids generating Optional<Optional<Organization>>.

This is more accurate than the common metaphor "a monad is a box that holds values": a monad provides a context-aware, dependency-driven ordering of computations. The meaning of ordering depends on the context:

• Maybe / Optional: If one step is empty, subsequent steps halt;
• Either / Result: If one step fails, the error is propagated;
• List: Each step may produce multiple results, enabling combination;
• State: State is passed from one step to the next;
• IO: External interactions are represented as composable actions.

Formally, a monad must satisfy the left identity, right identity, and associativity laws. While engineering code doesn’t typically require manual verification of these laws, they explain why reordering a chain of operations (without changing their semantics) should preserve the same outcome.

Don't Automatically Label Similar APIs as Monads

Java Optional.flatMap resembles a Monad's bind, but Java's API also includes null handling, object semantics, and other inherent conventions. Java Streams feature map and flatMap, yet these are lazy, single-consumption operation pipelines, stages that can be omitted without affecting the final result.

Thus, a safer characterization is that these APIs borrow functional composition patterns. Whether they constitute a formal instance of a specific pattern must be clearly defined in terms of types, operations, and equivalence relations. It's not valid to simply assert monadic behavior based on similar method names.

Put Errors Into Return Types

Exceptions diverge from normal return paths. For predictable business failures, explicit result types can be used:

sealed interface Result<T> {
    record Ok<T>(T value) implements Result<T> {}
    record Error<T>(String code, String message) implements Result<T> {}
}

Composite functions can decide whether to stop on the first error or accumulate multiple validation errors. The caller sees failure possibilities at the type level, there's no need to inspect the implementation and only discover that some part throws an exception.

This doesn't mean every exception should be converted into a return value. Memory exhaustion or violations of internal invariants (unrecoverable runtime failures) are fundamentally different from issues like "invalid email format." Error modeling must distinguish between expected business branches and program defects.

Side Effects Are Not Eliminated by Abstraction

Functional languages still need to read and write files, access networks. The key is to separate the composition of actions from their actual execution, ideally, to concentrate side effects into well-defined boundaries.

In a typical Java service, a straightforward approach might look like this:

sealed interface CheckoutEffect {
    record SaveOrder(Order order) implements CheckoutEffect {}
    record PublishEvent(OrderPlaced event) implements CheckoutEffect {}
}

record CheckoutDecision(
    Order order,
    List<CheckoutEffect> effects
) {}

The pure core produces CheckoutDecision, while the shell interprets and executes effects. This allows rule testing to avoid actually writing to databases, and makes the ordering, retrying, and idempotency requirements of side effects clearly defined and testable.

It does not automatically resolve consistency across databases and messaging systems; the execution layer may still require transactional message queues, idempotency keys, and other infrastructure-level guarantees. Abstraction can expose the boundaries of problems, but it cannot replace the need for infrastructure-level assurances.

The Order of Learning Abstraction

1. First, become fluent with pure functions and immutable values;
2. Use map, filter, and fold to describe common transformations;
3. Identify combinable aggregate operations;
4. Distinguish between independent and dependent computations;
5. Finally, learn the formal patterns of Functor, Applicative, and Monad.

An abstraction should not be introduced into business code simply because it's functional, unless it makes error handling, composition, or boundary testing clearer.

Completion Check

Design a registration flow: validate name, email, and password, then look up a referrer, and finally generate pending persistence and notification actions.

• Which validations are independent and can accumulate errors?
• Which step must depend on the output of the previous one?
• Are some operations purely computational, and which introduce side effects?
• Does the composition of operations satisfy the associative law?
• How can we avoid duplicate notifications when retrying actions?

Being able to answer these questions demonstrates true understanding of abstraction, remembering "a monad is a box" is far from sufficient.

References

• A Gentle Introduction to Haskell: About Monads
• Java SE 26: Optional
• Java SE 26: Stream