8861 Lab

Sign in Subscribe

Latest — 19 Mar 2026

The Hotel — A Distributed System From First Principles

Every pattern in the Core Concepts series has a working implementation. This is where it lives. The Lab series designs a hotel management system from first principles — one capability at a time, one pattern at a time. Before a line of code is written, the capabilities are identified, their boundaries

More issues

How Capabilities Connect

A single capability is a bounded unit of ownership. It processes commands, maintains its own state, publishes events, and reacts to facts from the outside world. Understanding what a capability is gets you halfway there. The other half is understanding how capabilities connect — how a single intent ripples through a

The Capability — The Unit of Architecture

Every pattern in this publication — event contracts, orchestration, choreography, domain boundaries, trust envelopes — ultimately applies to one thing. The capability. It is the unit of architecture in Relative Architecture. Understanding what a capability is, what it contains, and how it connects to everything around it is the foundation everything else

Business Provides Clarity. Product Writes Contracts. Engineering Implements Them. Infrastructure Makes It Real

Relative Architecture works in practice when four distinct roles are fulfilled. They may be inhabited by one person or many, by existing teams or new ones. What matters is that the responsibilities each role carries are clearly owned. The four roles are Business, Product, Engineering, and Infrastructure. Business, Product, and

What you will leave with

Four roles. Four different reasons to be here. If you are a business leader You will understand why your technology investments keep producing systems that are hard to change — and what a different approach looks like. You will be able to have an informed conversation with your architects and engineers

The Phone Calls Were Always This Model

The responsibilities never changed. The medium did. Understanding why a responsibility-based architecture matters now requires understanding how business integration has evolved across three generations. Not three generations of technology — three generations of how organisations actually fulfill their responsibilities and connect them to each other. Generation 1 — Analog Internal Organisations fulfilled

A domain owns its vocabulary. It never borrows from its callers

Manifesto line eight — domains organize responsibilities and their vocabulary — carries a consequence that is easy to miss. The vocabulary a domain uses to describe its work is not negotiable with its callers. A domain that names things the way its consumers name them loses its own identity. It becomes pulled

The Event Contract Is the Only Boundary That Matters

Why the schema of what your system publishes is more architecturally significant than the framework it runs on, the database it uses, or the team that built it. There is a thought experiment worth doing before designing any distributed system. Imagine you need to replace one of your services completely.

Orchestration and Choreography Are Not Opposites

They operate at different levels of the same system. Choosing between them is a false dilemma that produces worse architectures than understanding why both exist. Every serious distributed systems discussion eventually arrives at the same question. Should we orchestrate or choreograph? The canonical answer is that you should pick one

The same model, all the way down

A single booking at one gym. A gym chain operating across twenty locations. A fitness network connecting hundreds of operators. A global platform serving millions of members. The same model applies at every level. Each level has responsibilities. Each fulfils them through capabilities. Each communicates through intent and events. Each