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 system, how accountability transfers from one capability to the next, and how coordinated outcomes emerge from independent reactions without any single coordinator directing the sequence.
That is what this post is about.
The Trigger
Every chain of capability interactions starts with a trigger. A member submits a command. A timer fires. An external event arrives. Something crosses a capability's boundary and the process begins.
In the hotel domain — the one we use throughout the Lab series — the trigger is a guest checking in. The front desk submits a CheckIn command to the Reservations capability. Reservations owns this process. It validates the booking, confirms the room is ready, and produces an outcome.
That outcome — GuestCheckedIn — is the event that starts the cascade.
Two Kinds of Connections
When GuestCheckedIn is published, other capabilities react. But not all reactions are the same kind. There are two fundamentally different ways a capability connects to what happens next.
Nested — control returns
Some capabilities must complete their work before the originating process can continue. When Reservations confirms a booking it needs to know the room assignment before it can tell the guest where to go. Room Assignment is a dependency. Reservations submits a command — AssignRoom — and waits. Room Assignment processes the request, finds the best available room based on its own policies, and returns the outcome. Control returns to Reservations. The process continues.
This is a nested connection. The originating capability reaches out, waits for a response, and incorporates the result before proceeding. The dependency is synchronous within the process. Without it the process cannot advance.
Reservations
→ AssignRoom (nested — waits for response)
← RoomAssigned
→ continues with room number confirmed
Downstream — control does not return
Other capabilities react independently after the originating process has completed. When Reservations publishes GuestCheckedIn, the Bellhop capability reacts and arranges luggage delivery. The Valet capability reacts and parks the car. Housekeeping reacts and updates room status. None of these require Reservations to wait. None of them affect the outcome Reservations already produced. Reservations published the fact and its accountability for that outcome ended.
These are downstream connections. Each capability reacts according to its own rules. Each publishes its own events when its work is complete. The coordinated response to the guest's arrival emerges from independent reactions to a shared fact.
GuestCheckedIn
→ Bellhop reacts (downstream — Reservations does not wait)
→ Valet reacts (downstream)
→ Housekeeping reacts (downstream)
The Full Cascade
Put the nested and downstream connections together and the full picture emerges.
Guest submits CheckIn
↓
Reservations — BookingOrchestration
NESTED: AssignRoom → RoomAssigned
NESTED: AuthoriseCard → CardAuthorised
TERMINAL: GuestCheckedIn
↓
DOWNSTREAM: BellhopProcess (Concierge)
DOWNSTREAM: VehicleParked (Valet)
DOWNSTREAM: RoomStatusUpdated (Housekeeping)
DOWNSTREAM: WelcomeNotification (Notifications)
The nested processes — room assignment and card authorisation — must complete before the booking can be confirmed. They are inside the Reservations process. Control passes to them and returns.
The downstream processes — bellhop, valet, housekeeping, notifications — react to the terminal event. They are outside the Reservations process. Reservations does not know they exist. It published a fact. What happens next is the business reacting to that fact according to its own rules.
Accountability Follows the Boundary
One of the most important things the cascade diagram makes visible is where accountability lives.
Reservations is accountable for the booking outcome — confirmed or rejected, room assigned, card authorised. That is its responsibility. It owns the process end to end up to the terminal event.
Concierge is accountable for the luggage. Valet is accountable for the car. Housekeeping is accountable for the room status. Notifications is accountable for the welcome message. Each owns its downstream process completely. None of them depend on each other. None of them need Reservations to coordinate them.
When something goes wrong in a downstream process — the bellhop cannot locate the luggage, the valet system is down — that is the downstream capability's problem to resolve. It does not cascade back to Reservations. The booking is confirmed. The guest has their room. The failure is localised.
This is what bounded ownership produces. Failures are contained. Changes are contained. Each capability can be modified, redeployed, or replaced without touching the others — as long as the event contracts hold.
What the Cascade Diagram Is
The cascade diagram is not a technical diagram. It is a business architecture artifact.
It shows how the business responds to a fact — who reacts, in what order, with what accountability. A business architect should be able to read it and confirm that it reflects how the business actually works. A developer should be able to implement each capability from it without needing to know about the others.
The diagram is derived from the contracts. If every capability publishes a defined set of events and subscribes to a defined set of events, the cascade is a consequence of those contracts — not something that needs to be separately designed. Draw the contracts correctly and the cascade emerges.
This is why the event contract post argued that contracts are the only boundary that matters. The cascade is what the contracts produce when capabilities are connected. Change a contract and you change the cascade. Keep the contracts stable and the cascade is stable regardless of what changes inside any individual capability.
When Cascades Get Complex
Simple cascades — one trigger, a handful of reactions — are easy to reason about. Real systems are more complex. A downstream reaction publishes its own terminal event. That event triggers further reactions. The cascade becomes a graph rather than a tree.
The hotel checkout cascade illustrates this:
GuestCheckedOut
↓
DOWNSTREAM: InvoiceGenerationProcess (Finance)
TERMINAL: InvoiceGenerated
↓
DOWNSTREAM: PaymentProcess (Billing)
DOWNSTREAM: SurveyScheduled (Guest Experience)
DOWNSTREAM: RoomReleasedProcess (Housekeeping)
TERMINAL: RoomAvailable
↓
DOWNSTREAM: RoomAssignment updated (Reservations)
The checkout event triggers Finance and Housekeeping independently. Finance generates an invoice — its terminal event triggers Billing and Guest Experience. Housekeeping releases the room — its terminal event updates Reservations' room availability projection.
No single coordinator directed this. Each capability reacted to the fact it cares about, produced its own outcome, and published its own terminal event for whoever cares about that. The coordinated checkout process emerged from independent reactions in a chain.
Reading the Cascade
Three questions are worth asking about any cascade:
Who owns this step? Every process in the cascade has exactly one owner. If you cannot name the owner, the boundary is in the wrong place.
Is this nested or downstream? Does the originating capability wait for this response before proceeding, or does it react after the fact? The answer changes the contract, the error handling, and the operational monitoring required.
Where does accountability end? For each capability in the cascade — what is it responsible for and what is not its problem? The answer should be unambiguous. If it is not, the boundaries need to be redrawn.
The System as a Network
A system built from well-designed capabilities is a network of contracts and reactions. Each capability is a node. Each event contract is an edge. The cascade is the path a fact takes through the network.
The network is not designed top-down. It emerges from the contracts each capability defines for itself. Add a new capability — a loyalty program, a dynamic pricing engine, a partner integration — and it joins the network by subscribing to the events it cares about and publishing the facts it produces. Nothing else changes.
This is what the manifesto means by system behavior emerges from networks of collaborating responsibilities. The cascade diagram is that emergence made visible. Each capability doing its job, publishing its facts, reacting to others' facts — and the coordinated business outcome appearing as a consequence.
This is the fourth post in the Core Concepts series. The previous posts covered the patterns (orchestration and choreography), the boundary mechanism (event contracts), and the unit of architecture (the capability). This post shows how those units connect into a system. The Lab series builds a working version of these patterns from first principles — starting with the hotel check-in domain.