ReasonStack
Menu

— What is ReasonStack?

A named method for building systems you can reason about.

ReasonStack is event modeling and event sourcing on a substrate that doesn't drift. The method is open and adoptable on its own; Grain and Orc are its implementations, and Allium is the spec layer we've adopted to sit between them. The point is the same one Rich Hickey has been making for years: build Simple systems you can hold in your head.

— How it works

From a diagram to a system that can't drift.

01

Model the events

Design with Event Modeling — the same diagrams Grain's primitives map onto one-to-one. The events are the design.

02

Build from the closed set

Everything is one of seven primitives. The vocabulary is small on purpose, so an agent can't invent its way into chaos.

03

Bottom out at storage

Constraints are shallow and bottom out at the event store. The codebase bounds the space of valid outputs — drift becomes structurally impossible.

Tests stay in the loop as guardrails, not gospel. The substrate is what makes the difference: not a smarter harness around the model, but a floor underneath it.

— The seven primitives

The controlled vocabulary.

If something doesn't fit one of these categories, it's wrong. That closed set is the whole trick.

01

Events

the source of truth

Immutable, atomic facts: a thing that happened. The connective tissue between everything in Grain — and the one primitive with no def-macro.

02

Commands

packaged intent

A request to change state, carrying params, a schema, and an authorized predicate. The only way to change state.

03

Queries

the read path

The primary way to read state without producing events. Convention: a query is usually a whole screen.

04

Read models

projections

Pure reducers that fold a declared set of event types into current state. Your database is your system of read models.

05

To-do processors

react async

Subscribe to events and react — preferably by calling a command. The basis of event-driven workflows.

06

Periodic tasks

on a schedule

Run on an interval or cron; typically emit an event for a to-do processor to handle.

07

Schemas

the glue

Declare the names and types for command/query inputs, event bodies, and read-model shapes. A data shape, not a database row.

— See it in real code

The theory bottoms out in a repo you can read.

Rather than a hypothetical, the method is demonstrated in one small, complete application — grain-todo-list. There is no tasks table you mutate; a task is a fold over its own events. State is a projection. You never edit — you append.

Read the pattern compendium ↗
// a task, as events — never a mutable row
TaskAdded → TaskCompleted → TaskReopened
state = fold(events)
// the list is a read model
open = tasks where not done
// the history is the truth. you append, never edit.

— Lineage

Standing on known ideas.

None of this is invented from scratch. ReasonStack enriches a deep lineage of thinking about simplicity, events, and information systems.

Rich Hickey

Simple Made Easy · Are We There Yet? · Design, Composition, and Performance

Adam Dymitruk

Event Modeling — the methodology Grain's primitives map one-to-one onto

Bobby Calderwood

Commander (Strange Loop) — CQRS / event sourcing, simplified into Grain

Martin Fowler

Event sourcing — an influence on the path

Datomic / XTDB

Event-store protocol, total ordering, bi-temporality

EventStorming / DDD

The discovery activity, and the contrast point for 'no aggregates'

Behavior trees

Robotics and game-AI literature — the basis for Orc

re-frame (day8)

The open-source shape: an authoritative spec, a reference implementation, and exhaustive tests