The functional core, mutable shell architecture is how I recommend using Commanded, an open source library for event sourcing.

Aggregates and process managers are the building blocks which are used to host the functional core. These are where you write pure functions:

• Aggregate:
  • f(state, command) => list(events)
  • f(state, event) => state
• Process Manager:
  • f(state, event) => list(commands)
  • f(state, event) => state

Decisions are always recorded as domain events (as an immutable list of domain-specific facts).

Commanded provides the imperative shell to host the above pure functions in GenServer processes and takes care of all IO, such as fetching and persisting events.

Event handlers are used for side-effects where impure functions can be implemented which react to events and call out to the external world. This could be sending an email, interfacing with a payment gateway, or updating a read-only projection of an aggregate’s events. They can also feed back into the functional core by sending commands to aggregates.

One benefit of the above approach is that aggregates (containing your business logic) can be tested free from any IO concerns as:

• Given: initial event(s)
• When: command
• Expect: resultant event(s)

I feel the part you’re missing is that your functional core alone is not your domain API. It can’t be if the domain you’re handling is in any shape or form stateful. What the architecture suggests is separating the pure domain logic (how are discounts applied to prices of an order) from stateful/external dependencies (discount code in the DB).

Your functional core cannot answer the question of “is this discount code valid on the current date”. What it can do is “is this discount code valid given this lists of discount code availabilities and a date of usage”.

Event sourcing is another great way of implementing this pattern too. Instead of returning values and a callback function (ie a free monad), return an event, then an event handler runs to actually execute the side effect.

If you squint hard enough, they’re the same thing, just different (AKA they’re “isomorphic”). The emitted event =~ the returned value, and the event handler =~ the “next” function.

In real world coding, I’ve used event sourcing many times to handle use cases with side effects mixing with pure code like the one we’re talking about here - but not the free monad/interpreter pattern I’m talking about in that talk. Would be interesting to, but for a lot of teams would be too “out there”