Foundations
The ephemeral context
Each time the domain is applied to an intention, it runs inside a container built for that one event and thrown away afterwards. Nothing you resolve leaks into the next request. This single rule removes most of the state bugs that plague long-lived servers.
#One container per event
The principle
Shared mutable state across requests is the source of the hardest server bugs: leaked user data, order-dependent behaviour, memory that grows request by request. If each event gets its own isolated scope, those bugs cannot form.
In Stone.js
For every incoming event, the kernel spins up a fresh service container, resolves your handlers and services into it, runs them, and discards it. What you register as a singleton lives for that one event, not for the process.
Nothing survives the request that should not. The blank slate is the default, not a discipline you enforce.
#What stays, what goes
The adapter is the only long-lived thing: it holds the connection to the platform and builds a new context per cause. The Blueprint is built once and read-only. Everything else, the container and everything in it, is per-event.
@EventHandler('/tasks')
export class TaskController {
// Built fresh for THIS event. Fields here are safe: they cannot bleed
// into another request, because this instance does not outlive the event.
private readonly tasks: TaskService
constructor ({ tasks }: { tasks: TaskService }) { this.tasks = tasks }
}#Why serverless fits perfectly
The ephemeral model and serverless runtimes are made for each other. A Lambda or a Worker already gives you a short-lived execution per invocation; the per-event container matches that grain exactly. There is nothing long-lived to warm except the adapter, so the domain pays no tax for running on the edge.