execution domain

one operation needs one place where its runtime facts — scope, diagnostics, release boundary, verification — are established. these group because they share a single lifecycle: they are created when the boundary opens, carried through every call underneath it, and proven when the release ships. without an owning domain, context leaks into signatures and verification becomes an unowned ritual.

this domain owns a decision when the question is one operation's runtime context — execution scope, typed diagnostics, the release boundary, and live verification. how code reads belongs to the code domain; durable facts belong to the persistence domain.

• async local execution context
• framework entrypoints
• cloudflare stack
• diagnostic errors
• deployment and UAT

bad

request handler passes env, logger, and database through every function.

the operation scope is obscured by repeated technical dependencies. every function signature adds context parameters, making code verbose and brittle. when you need to add a new scoped facility (like a rate limiter), you must update every function signature in the call chain. testing requires manually constructing env objects. correlation IDs have no canonical owner.

good

entrypoint establishes execution context; services read scoped facilities.

the operation boundary owns runtime facts and can prove its diagnostics. each function signature states only its real domain inputs; context is implicit. adding a new scoped facility requires only an entrypoint change. testing becomes straightforward. correlation IDs flow automatically through the operation.