Methodology

Think in Processes, Not Tables

ReckonDB is an event store — but an event store is only as good as the way you model with it. This is how we architect on top of it: a process-centric method (the one behind our Hecate agents) that treats every business process as a folder of facts moving across desks.

The D4 Model

Why a dossier, divisions, departments, desks? Because our industry has a reflex — and it isn't built for processes.

Most teams model the data first — reach for tables, normalize, ask "what entities do we have?", bolt behaviour on after. The instinct says some things just are: a balance, a catalogue, a config file. But each is the leftover of a process. A balance is every debit and credit, folded — double-entry bookkeeping has stored the journal and derived the balance for seven centuries. A catalogue is whatever merchandising chose to stock. Even configuration — the last thing anyone calls a process — got wrapped in commits, reviews, rollbacks and drift-detection the moment it mattered; we named it GitOps and conceded that current state is a projection and the history is the truth.

So "static data" isn't a category — it's a process whose history you chose not to keep. Sometimes that's the right call (nobody event-sources the list of country codes). Far more often the history is the value — who changed this, when, why, can it be undone — and the data-first reflex discards exactly that, then spends years re-deriving it, badly, with audit tables and status columns. Event sourcing isn't exotic; it's the lesson our highest-stakes domains — money, source code, infrastructure — already learned. The rest of us just haven't been forced to admit it yet.

Horizontal layering finishes the job: split one process across controllers/, services/, repositories/ and it lives nowhere you can point to.

The theory has been written, too — but the canonical literature reads abstract: bounded contexts, ubiquitous language, aggregates, projections. Correct, and easy to bounce off. Teams nod, then go back to tables. What finally makes it land isn't more theory — it's a metaphor everyone already owns: an office.

C4 — structure

Simon Brown's model: what the system is made of, at zoom levels.

Context — the system in its world
Containers — apps & data stores
Components — the parts inside
Code — classes & functions

The floor plan.

D4 — process

This model: what happens, and where, as work flows.

Division — one bounded context
Department — process · file · answer
Desk — where one decision is made
Dossier — the folder of facts that moves through them

The day's work.

Three of the four are structure; the fourth — the Dossier — is the dimension C4 leaves out: it moves. You want both lenses. But if you've ever struggled to explain a process to a room that thinks in tables, D4 is the language that lands.

Five Principles

Process over Data

Ask what happened to a thing, not what it is right now.

Vertical over Horizontal

A feature lives in one folder. No services/, utils/, helpers/.

Strict over Creative

When patterns are strict, the mechanical parts template themselves.

Explicit over Clever

Name things for what they do — announce_capability, not handler.

Events Are Sacred

Immutable facts about what happened. Never mutate, never delete — append only.

The Dossier Principle

An aggregate is not a row that gets overwritten. It's a dossier — a folder of event slips that accumulates as it moves across desks. The dossier is its history.

A folder moving through an office

A request for change (a command) lands on a desk.
The clerk pulls the dossier and reviews the slips inside (the events so far).
The clerk decides whether the change is allowed — the business rule: "can this slip be added?"
If allowed, the clerk files a new slip (a new event); otherwise the request is refused.
The dossier moves on to the next desk.

The command is the request; the slip is the fact it produced. "Rebuilding state" is just reading the dossier — folding its slips to see where things stand.

Dossier: user-mri:user:acme/ada
├── [slip] user_registered_v1     ← register_user desk
├── [slip] user_email_changed_v1  ← change_email desk
├── [slip] user_promoted_v1       ← promote_user desk
└── [slip] user_suspended_v1      ← suspend_user desk

Data-centric

"What is this thing now?" — events mutate a state object.

Process-centric

"What happened?" — the ordered slips are the truth.

The Company Model

Each bounded context is a Division — a small specialist firm with three departments. Work arrives at frontdesks, gets processed at backoffice desks, and the read side answers questions from filing cabinets.

📨

CMD

Processing

Receives intents (commands), validates them, and adds event slips to the dossier. The write side.

🗄️

PRJ

Filing

Subscribes to events and keeps the filing cabinets (read models) up to date. No business logic — just filing.

🔎

QRY

Inquiries

Answers questions by reading the filing cabinets — fast, no joins, no recomputation. The read side.

Departments talk through facts, never direct calls: CMD emits an event, PRJ files it, QRY serves it. A desk is the unit of work — one capability, one folder, its own supervisor.

Vertical Slicing

Add a feature → add a folder. Delete a feature → delete a folder. No archaeology.

❌ horizontal
src/
├── controllers/
├── services/
├── repositories/
└── models/

✓ vertical
src/
├── register_user/
├── promote_user/
└── suspend_user/

Screaming Architecture

A stranger should know what the system does from the folder names alone. Names scream what, not how.

handlerregister_user

user_createduser_registered_v1

order_serviceconfirm_order

Directories are verb + noun. Events are past tense. No CRUD verbs — business verbs.

The Workflow

Building a system is itself a set of processes — each a first-class dossier with its own lifecycle. Work nests four levels deep:

Venture          the whole endeavour
└── Division     one bounded context
    └── Department   CMD · PRJ · QRY
        └── Desk         a single capability

Venture lifecycle

Set up the venture (once), then discover divisions — the bounded contexts worth building.

Division lifecycle

Each division runs two processes in sequence: Planning (event-storm, design aggregates & desks) → Crafting (generate, test, deliver).

Node lifecycle

A running node has no phases — it registers, serves, and stays alive, announcing what it can do.

Every process has the same lifecycle

Each long-lived process is a dossier that moves through one shared protocol. Domain work only happens while it's open; concluding one process hands off to the next.

initiate ─► initiated ─► open ⇄ shelved ─► concluded
                          (work happens here)        │
   any state ───────────────────────────────► archived
                                              └─► hands off to the next process

How You Actually Drive It

You don't fill in forms — you have a guided conversation. At each step the method frames one decision, lays out the trade-offs, and lets you choose. Every decision narrows the next.

1. Frame

One bounded decision, no ambiguity.

2. Present options

Trade-offs as a table — pros and cons, not opinions.

3. You decide

You own the choice. It's never made for you.

4. Record

The decision becomes a constraint on everything after.

5. Build forward

Each choice shrinks the next decision's space.

6. Produce an artifact

The output is structured data, not prose.

Build with the grain

Process-centric, event-sourced, and strict enough to generate. Start with the event store.

Get Started See It in Action