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 builds on.
What a Capability Is
A capability is the software realisation of a business responsibility. It owns everything required to fulfil that responsibility — the rules that govern its decisions, the vocabulary it uses to describe its domain, the state it maintains, and the processes it executes.
A capability exposes exactly two surfaces to the outside world: the commands it accepts and the events it publishes. That is the complete contract. Everything else — the database schema, the internal data model, the framework it runs on, the language it is written in, the table names, the field types — is invisible to every other capability in the system. Not discouraged. Not hidden by convention. Invisible by design.
This is not a guideline that gets relaxed when things get complicated. It is the boundary. A capability that shares its database schema with another capability has no boundary. The two capabilities are a distributed monolith — all the operational complexity of distribution with none of the architectural benefits of separation.
The only path across the boundary is a command or an event. If another capability needs information that lives inside this one, it either submits a command and receives an outcome, or it subscribes to the events this capability publishes and maintains its own local projection from what it receives. There is no third option.
The Inside — Two Concerns, Six Components
The internal structure of a capability separates two fundamental concerns: execution and knowledge.
Execution — the left side
Commands are the intents a capability receives. A requestor submits a command expressing what outcome they need. The command names the desired outcome and passes the context required to fulfil it. The capability decides whether and how to fulfil it — that decision is never the requestor's to make.
Process is where the work happens. The capability evaluates the command against its policies, executes the steps required to produce the outcome, coordinates any dependencies it needs, and produces the result. The process is the capability's responsibility end to end.
State is the in-flight record of work in progress. Open reservations. Pending payments. Active sessions. State is operational — it reflects what is happening right now, not the permanent record of what has happened.
Knowledge — the right side
Projections are the capability's view of the world assembled from events it has observed. Rather than querying other capabilities directly, a capability maintains its own local projection of the facts it needs. A reservation capability does not call the scheduling capability to find out if a class exists — it maintains a projection of scheduled classes built from events the scheduling capability published. Projections are read-only, local, and derived.
Policies are the rules that govern the capability's decisions. What conditions must be met for a command to be accepted. What constitutes a valid state transition. What triggers a compensating action. Policies encode the business rules the domain owns.
Entities are the permanent record — the things the capability knows about and is responsible for maintaining. A reservation is an entity. A member is an entity. A class slot is an entity. Entities persist. State is transient. The distinction matters operationally.
The Operator
The operator at the base of the capability diagram is not an afterthought. It is a deliberate acknowledgment that a capability is not purely software.
The operator is the human steward of the capability — the person or team responsible for the rules it enforces, the exceptions it cannot handle automatically, and the judgment calls that fall outside what the policies can resolve. In Generation 1 the operator was the entire capability. In Generation 3 the operator handles what automation cannot.
A well-designed capability makes the operator's job tractable. The policies handle the routine. The process handles the execution. The operator handles the edge cases — and has the visibility and tooling to do so effectively. A capability that buries its operator in routine work has not automated enough. A capability that removes the operator entirely has automated too much.
The Outside — Four Relationships
A capability connects to the outside world through four distinct relationships. Each is different in direction, purpose, and contract.
Requestors submit commands and rely on outcomes. They express intent — what they need the capability to do — without prescribing how. The capability owns the how entirely. The requestor owns the what. This separation is what keeps capabilities independently changeable. A requestor that dictates implementation has broken the boundary.
Dependencies are capabilities this capability relies on to fulfil its own responsibilities. When a reservation capability needs to validate a membership instrument, it submits a command to the entitlement capability. The entitlement capability is a dependency. The reservation capability cannot proceed without its response — this is the nested process pattern, where control passes to a dependency and returns before the owning process can continue.
Informers publish facts the capability subscribes to. The capability does not call the informer. It does not query the informer's database. It subscribes to the informer's event stream and maintains a local projection from what it receives. The informer does not know who is listening. The interested party does not know who published. The event contract is the only connection between them.
Interested parties receive the facts this capability publishes. When a capability completes a process and produces an outcome, it publishes an event. Every capability that cares about that fact can react. Every capability that does not care ignores it. The publishing capability does not know its subscribers. It fulfils its responsibility, publishes the fact, and its accountability for that outcome ends.
The Boundary Is the Architecture
The capability boundary has no preferred direction — commands can come from anywhere, events can flow in any direction, dependencies can point anywhere in the system. What matters is not the topology but the nature of each relationship.
Requestors and dependencies cross the boundary with intent — they expect an outcome. Informers and interested parties cross the boundary with facts — they share what happened without expectation of response.
The most common way boundaries fail in practice is the shared database. Two capabilities that read and write the same database tables are not two capabilities — they are one capability split across two deployments. Every schema change in one is a breaking change in the other. Every query one makes against the other's tables is a coupling that will eventually surface as a production incident nobody can explain.
The test is simple: if you changed this capability's database schema completely — renamed every table, restructured every relationship — would any other capability break? If yes, the boundary has been violated. The other capability is depending on something it was never supposed to know about.
Commands and events are the only surfaces. Intents cross the boundary in. Facts cross the boundary out. Everything else stays inside. That discipline — maintained consistently, enforced at every design decision — is what makes a capability independently deployable, independently changeable, and independently testable.
How the boundary is implemented internally is the developer's decision. The patterns available — hexagonal architecture, ports and adapters, clean architecture — are all valid approaches to structuring the inside of a capability. That choice belongs to the engineering team. What is not a choice is the boundary itself. It holds regardless of what pattern implements it.
Draw the boundaries correctly and hold them. The system will thank you for years.
The capability model is the foundation of everything else in this series. The event contract defines what crosses the boundary. Orchestration describes how a capability manages its own process. Choreography describes how capabilities react to each other's published facts. Identity and trust describe how capabilities know who is crossing their boundary and whether to honour the request. All of it applies to this one unit.