DomainConfig | Cessy Builder Docs

DomainConfig is the app model. It is the contract the Builder UI edits, the Design MCP inspects, and the runtime materializes after publish.

Draft and published config

State	Meaning
Draft	Design-time state under active work. It can live in the main draft or an isolated workspace.
Changeset	A reviewable set of workspace changes with validation results.
Published	The model currently used by runtime APIs, agents, webhooks, subscriptions, and pages.

Keep draft exploration separate from published runtime behavior. Publish only after validation and a concrete smoke test plan.

Commands

Commands are business requests. They should read like a user or system asking the app to decide something:

PlaceOrder
ApproveInvoice
AssignCaseOwner

A command schema defines the input fields and refined types. The command handler validates current state and emits events. It should not perform caller-side orchestration, dedupe, lookup-before-create, or cross-bounded-context coordination.

Events

Events are durable facts. They should use past-tense names and carry the data needed by projections, policies, audit, and future decisions:

OrderPlaced
InvoiceApproved
CaseOwnerAssigned

Events are append-only business history. If a later workflow needs different read data, add or rebuild projections instead of editing historical facts.

Projections

Projections answer runtime questions. Model them around actual user and integration needs:

list current orders
show open cases by priority
export billing activity for one account

Projection query behavior is documented in Projection Queries.

Policies

Policies react to events. Use them for automation, external side effects, command dispatch, agent wakeups, adapter calls, and webhook-driven workflows.

Keep policy intent explicit. If the automation is business-critical, make the triggering event and resulting command visible in the model.

Permissions

Permissions define who can execute commands and read projections. Model roles and attributes in the app instead of hiding checks in custom frontend code.

See Permissions for the runtime implications.

Agents and pages

Agents and custom pages are not separate products bolted onto the app. They should use the generated runtime surfaces and stay aligned with DomainConfig:

Runtime MCP exposes command and projection tools to app agents.
Custom pages call runtime commands and projections.
Design MCP helps builder agents inspect and change the design model.