Domain creation

Workflow

Domain creation

agent starscribe

Derivation Chain

Actions + Events → Aggregates → DBML Models
                → Requirements (passed to feature loops)
                → Flow outlines (standalone *.flow.mdoc files)

Phase 1 — Action/Event Discovery

Ask the user to describe what happens in this domain without structure or order. Capture both past-tense events and imperative commands:

Events: past tense, PascalCase — one thing that occurred (UserRegistered, SessionExpired)
Commands: imperative, PascalCase — one thing requested (RegisterUser, ExpireSession)
Operations: request/response interactions (GetProfile, SearchUsers) — capture what they return and how they fail
No filtering — capture everything
Do not ask about models or structure yet

Phase 2 — Sequence Ordering

Arrange pairs into a chronological narrative:

[start] → RegisterUser → UserRegistered → ValidateCredentials → CredentialsValidated → SessionCreated
                                                               ↘ CredentialsRejected (Error) → AccountLocked

Ask: what is the happy path? Where do branches occur? What are the named failure modes?

Phase 3 — Interaction Pairing

Pair every command with the event it produces, and every operation with its result and errors.

Interaction	Result / Event	Failure Modes (Errors)
RegisterUser (Action)	UserRegistered	n/a (async)
GetProfile (Op)	Profile Data	ProfileNotFound
CreateOrder (Op)	Order ID	InsufficientFunds

Derivation checkpoint: From these pairs you can sketch:

Requirements for the feature loop: “The system must support RegisterUser…”
Flow outlines: sequences of pairs that become *.flow.mdoc files

Phase 4 — Aggregate Discovery

Group command-event pairs by the entity that handles them. Each group becomes a DBML table.

User aggregate:
  RegisterUser → UserRegistered
  LockAccount  → AccountLocked

Session aggregate:
  ValidateCredentials → CredentialsValidated
  CreateSession       → SessionCreated

Phase 5 — Policy Discovery

Identify automatic reactions: “When [event], then automatically [command].”

When CredentialsRejected (3rd time) → LockAccount

Phase 6 — Glossary

Formalize domain vocabulary discovered in phases 1–5. Ask: “Is there any term that needs a precise definition to avoid ambiguity?”

Phase 7 — DBML Model

Translate aggregates to DBML. Fields are derived from what commands need and events must record.

Phase 8 — Draft & Confirm

Present the complete .domain.mdoc draft for user confirmation before writing. Output: content/domains/{id}.domain.mdoc

Do’s and Don’ts

Do:

Let actions and events drive all other artifacts — models, requirements, and flows are derived, not invented independently
Capture every action and event the user mentions without filtering during discovery
Pair every command with its resulting event before moving to aggregates
Use the derivation chain (actions/events first, then aggregates, then DBML) strictly in order
Present the full draft for confirmation before writing anything to disk

Don’t:

Don’t start with models or data structures — always start with actions and events
Don’t skip the glossary phase; ambiguous terms cause downstream confusion
Don’t merge separate aggregates just because they share a field
Don’t invent actions or events the user did not mention without flagging them as suggestions
Don’t write the file before the user explicitly confirms the draft

Definition of Done

Draft presented to user for confirmation
Document written as content/domains/{id}.domain.mdoc with correct frontmatter and root tag
All action/event pairs are complete and consistent
DBML models are derived from aggregates, not invented independently
All cross-references resolve to existing documents
pnpm compile succeeds