Model A Business App

Good Cessy modeling starts in business language and ends in runtime contracts. Use this guide when designing a new workflow or reshaping an existing one.

1. Name the decision

Ask: what is the app deciding?

Good command names describe the request:

  • SubmitApplication
  • ApproveRefund
  • AssignTechnician

Avoid generic CRUD names unless the business action really is generic record maintenance.

2. Identify the facts

For each command, list the facts that must be recorded if the decision succeeds. Event names should be past tense:

  • ApplicationSubmitted
  • RefundApproved
  • TechnicianAssigned

Keep events meaningful to future readers. A projection, policy, audit view, or later command may need those facts.

3. Define decision state

A decider needs enough event history to validate the command. Define the scope intentionally:

  • What entity or group of entities does this decision depend on?
  • Which event types must be loaded?
  • Which command inputs identify the event stream or DCB criteria?
  • Should the write append to the same scope that was read?

If the decision reads one scope and writes another, document why.

4. Build read models

Projections are not database tables for their own sake. They answer questions:

  • What should the user see on a list page?
  • What should an external integration query?
  • What context should a runtime agent load before acting?
  • What operational view helps debug failures?

Design projection fields, filters, and sort keys around those questions.

5. Add automation deliberately

Use policies when events should trigger follow-up behavior:

  • dispatch another command
  • call an adapter
  • wake an agent
  • send a webhook or notification
  • run custom code in the sandbox

Keep policy effects visible in the model so builders can reason about cause and effect.

6. Protect the workflow

Add permissions after the workflow is clear, then test them first. A command that looks correct but is callable by the wrong actor is not ready.

Use roles and attributes to express business access. Avoid hiding permission logic in custom pages or external clients.

7. Verify through runtime surfaces

After publish:

  • inspect generated OpenAPI
  • execute one representative command
  • read the projection that should reflect the event
  • check Activity and errors
  • verify any runtime agent or page that depends on the new behavior