Model the domain
Encode the real domain in a structure instead of distributing it across
booleans, conditionals, loose parameters, and lifecycle checks.
Find the missing shape
- Trace the states, transitions, invariants, ownership, and dominant access
paths in the current code.
- Locate repeated shape assumptions, synchronized booleans, growing branches,
ad hoc mutation, and phase-named modules that repeat the same domain rules.
- Choose the smallest structure that removes those problems. Candidates
include a state machine, typed model, discriminated union, registry, lookup
table, reducer, command/event model, queue, cache, index, graph, normalized
collection, or one module that owns a coherent body of domain knowledge.
- Compare the proposed shape with the current one. It must delete branches,
duplicated rules, invalid states, or lifecycle risk. Extra indirection alone
is not a benefit.
- Leave clear, local, stable code alone when no structure materially improves
it. Three explicit statements can be better than a premature abstraction.
State the invariant the model enforces, the access patterns it serves, the
invalid states it removes, and the migration boundary. Design work does not
authorize implementation beyond the user's request. Assess compatibility and
migration before changing a public API or persisted shape. Design alone does
not authorize commits, pushes, publishing, deployment, or external messages.
Adapted from Lauren Tan's PStack
principle-model-the-domain
at commit 60c641e4fad674784b30abcf9f8915dea39df38d under the MIT License.
See third-party notices.
1---2name: qstack-model-the-domain3description: Replace scattered domain assumptions with the smallest structure that removes invalid states and branching. Use when booleans have to be kept in sync, the same rule is validated at several call sites, a branch grows with every new case, or an invalid state can be represented at all.4license: MIT5---67# Model the domain89Encode the real domain in a structure instead of distributing it across10booleans, conditionals, loose parameters, and lifecycle checks.1112## Find the missing shape13141. Trace the states, transitions, invariants, ownership, and dominant access15 paths in the current code.162. Locate repeated shape assumptions, synchronized booleans, growing branches,17 ad hoc mutation, and phase-named modules that repeat the same domain rules.183. Choose the smallest structure that removes those problems. Candidates19 include a state machine, typed model, discriminated union, registry, lookup20 table, reducer, command/event model, queue, cache, index, graph, normalized21 collection, or one module that owns a coherent body of domain knowledge.224. Compare the proposed shape with the current one. It must delete branches,23 duplicated rules, invalid states, or lifecycle risk. Extra indirection alone24 is not a benefit.255. Leave clear, local, stable code alone when no structure materially improves26 it. Three explicit statements can be better than a premature abstraction.2728State the invariant the model enforces, the access patterns it serves, the29invalid states it removes, and the migration boundary. Design work does not30authorize implementation beyond the user's request. Assess compatibility and31migration before changing a public API or persisted shape. Design alone does32not authorize commits, pushes, publishing, deployment, or external messages.3334Adapted from Lauren Tan's PStack35[`principle-model-the-domain`](https://github.com/cursor/plugins/blob/60c641e4fad674784b30abcf9f8915dea39df38d/pstack/skills/principle-model-the-domain/SKILL.md)36at commit `60c641e4fad674784b30abcf9f8915dea39df38d` under the MIT License.37See [third-party notices](../../THIRD_PARTY_NOTICES.md).
hani-q