Domain Model

Records and code share one language only when each word is defined once: a term used without an entry means whatever each reader guesses. The entry fixes the meaning, the rejected synonyms, and the wider and narrower terms, so reviewers and checks read the same word the same way.

The term receipt carries the meaning "proof of payment accepted for an expense" in the glossary, so every record naming a receipt means that proof.

Reviewed forWhich terms do the Behavior records name without a glossary entry stating their meaning? Look at the records beside the project glossary.

Marked guidance: a reviewer answers this question.

Business words, design words, and implementation words age on different clocks: a business term moves when the market moves, a design term moves when the model moves, and an implementation term moves when the code moves. The record layer tells each reader which clock the word follows, and the aliases let industry readers find LiteSpec own words without learning a second vocabulary first.

The term saga carries layer: behavior with aliases: ["process manager"].

Checked bylitespec model check fails a glossary term without layer, and each behavior term lists the synonyms its readers know in aliases.

Marked checkable: the tool named here checks it.

A module relies on the language and behavior of others, and each reliance shapes change: editing a module ripples into everything depending on it. Naming every reliance in dependsOn shows that ripple as data instead of leaving it for readers to reconstruct from prose.

Reviewed forWhich modules rely on a module that dependsOn does not name? Look at the module pages beside the modules they rely on.

Marked guidance: a reviewer answers this question.

The kind decides what the page carries: an entity carries a lifecycle, a saga carries steps with compensations, exits, and drivenBy, and a store carries an owner with no guarded invariant. Without the kind, a thing kept consistent reads the same as a table the product only holds.

The refund saga declares kind: saga, and the suppression list declares kind: store.

Checked bylitespec model check fails an aggregate page without kind or with an unknown kind.

Marked checkable: the tool named here checks it.

A store holds state no aggregate invariant guards, so nothing in the model explains who answers for its shape: a library-owned table, a suppression list, or a delivery log. Naming the owner puts one party behind it, and keeps staff actions on it as ordinary use cases instead of unwritten operations.

Checked bylitespec model check fails a store aggregate page without owner.

Marked checkable: the tool named here checks it.

A bare state name tells a reviewer nothing: rejected without its meaning hides what rejection costs and allows. A name with a meaning makes each lifecycle step reviewable on the page, and gives transitions states worth connecting. An entity tracks what the thing is, and a saga tracks where its coordination stands. A store carries no lifecycle, so it carries no states.

The hold queue entity declares Requested, Ready, Collected, Cancelled, and Lapsed, each with one sentence saying what the hold awaits or has received.

Checked bylitespec model check fails an entity or saga page without states entries carrying a name and a meaning.

Marked checkable: the tool named here checks it.

A store holds state no aggregate invariant guards, so a lifecycle on it promises what nothing guards: states claim a reviewed path while any writer moves the rows. The store names its owner instead, as litespec/core/domain-model#name-the-owner-of-every-store states, and staff actions on it stay ordinary use cases.

The suppression list declares kind: store with its owner and no states.

Checked bylitespec model check fails a store aggregate carrying states.

Marked checkable: the tool named here checks it.

States without transitions are a list of names with no path between them: a reviewer sees where an aggregate rests but never how it moves. Listing every allowed change with the use case that moves it shows the whole lifecycle beside the states, and leaves no state reachable only by a path no record names. The state-unreached and transition-unknown checks report a state no transition reaches and a transition naming a missing state or use case.

Checked bylitespec model check reports state-unreached (level G) for a state reached by no transition, a creation included, and transition-unknown (level G) for a transition naming a missing state or use case.

Marked checkable: the tool named here checks it.

The kind decides how the rule is proved: an invariant on every change, a precondition before the behavior, a calculation through its examples, a cross-aggregate rule where aggregates meet, an atomicity rule naming its bound group, a reservation through its release, a commercial-data rule through its frozen value, a default through the value the model holds. A rule without a kind leaves each reader to prove it a different way, and the checks no place to confirm it.

rule/expense.reimbursed-once is an invariant stating "an expense is reimbursed at most once", checked on every reimbursement.

Checked bylitespec model check fails a rule entry without kind or statement.

Marked checkable: the tool named here checks it.

An atomic write across aggregates stays allowed only through its rule: the rule states the group and why, such as an order without its hold overselling, and the use case commits exactly that group, as the use-cases page states. A group above 4 aggregates is a saga candidate, reported at level A.

The hold rule binds the hold and the copy aggregates, so a hold without its copy never stands.

Checked bylitespec model check reports atomic-group-drift (level G) for an atomic use case whose changes differs from its rule's binds, and atomic-group-invalid (level A) for a group binding more than 4 aggregates.

Marked checkable: the tool named here checks it.

A name that drops the negation reads as its own opposite: a rule named cancel-after-shipment whose statement says "never" allows what it forbids. A restricting word keeps the name a true sentence a reviewer trusts without opening the statement, and one-grant-per-account already says what "an account never holds two grants" says. The rule-name-invalid check reports a rule whose statement negates while its name keeps no restricting word or uniqueness.

The rule reads rule/order.cancel-never-after-shipment.

Checked bylitespec model check reports rule-name-invalid for a rule whose statement says not, no, never, or cannot while its name keeps no restricting word or uniqueness.

Marked checkable: the tool named here checks it.

An aggregate page holds what one aggregate guarantees; a rule spanning aggregates guarantees what no single aggregate owns. Giving such rules their own page keeps each aggregate page a true account of its aggregate, and gathers the shared rules where a reviewer judges them together.

Reviewed forWhich cross-aggregate rules sit outside a rule page? Look at the rule entries beside their aggregate pages.

Marked guidance: a reviewer answers this question.

A guarded rule without a named refusal leaves the ending unnamed: callers branch on a refusal the records never predicted. Naming the refusal ties the rule to the result the use case declares, so the breach and the ending stay one fact.

Reviewed forWhich guarded rules name no refusal in refusal? Look at the rule entries beside the results they refuse.

Marked guidance: a reviewer answers this question.

A held claim with no release is a leak: places, funds, or names stay locked past their need, and nobody owns freeing them. Naming the releasing use case states the end of the hold beside its start, and { "mode": "never", "reason": "..." } with its cost admits a hold that truly lasts, with the price on record. Persistence claims the added keys and releases the removed ones in the commit that changes the aggregate (litespec/backend/persistence#claim-a-cross-record-key-at-commit). The reservation-release-missing check reports a reservation with no release.

Checked bylitespec model check reports reservation-release-missing for a reservation rule whose releasedBy names neither a use case nor { "mode": "never", "reason": "..." } with its cost.

Marked checkable: the tool named here checks it.

A price, fee, or rate read live changes under settled business: a refund follows today price instead of the price at sale. Naming when the value freezes pins each reading to its moment, and the retained link keeps the earlier values reachable for audit and dispute.

Checked bylitespec model check fails a commercial-data rule without frozenWhen or retainedIn.

Marked checkable: the tool named here checks it.

Two computations of one value drift: the screen shows one figure while the ledger records another, and each side cites its own code. Citing the same calculation rule on both use cases keeps one computation behind both faces. Code carries a mark naming the rule, and never the reverse.

Reviewed forWhich queries and commands computing one value cite different rules in computedBy? Look at the use cases beside the calculation rule.

Marked guidance: a reviewer answers this question.

A calculation stated only as a sentence hides its edges: reviewers agree on the words while each pictures other numbers. An examples table shows those edges, and the scenario proving the rule pins them as checked facts. The calculation-table-missing check reports a calculation rule with no scenario examples table.

Checked bylitespec model check reports calculation-table-missing for a calculation rule with no scenario examples table.

Marked checkable: the tool named here checks it.

An event without a meaning is a name every reaction interprets alone; facts without a carries list are reconstructed from code at each reaction. Stating both on the entry lets each reaction trust what happened and what arrived with it.

Checked bylitespec model check fails an event entry without meaning or carries.

Marked checkable: the tool named here checks it.

An event names a fact that completed, so the past tense tells a reader the business already moved: submitted reports, while submit orders. The past tense also pairs each event with the act raising it.

The expense aggregate raises event/expense.submitted for a completed submission.

Reviewed forWhich event names read as an order rather than a completed fact? Look at the event entries beside their raising acts.

Marked guidance: a reviewer answers this question.

The root is the one type through which outside behavior changes the aggregate, so it sees every change worth announcing. Raising each event there keeps the fact and its announcement in one step, and leaves no event announced for a change the aggregate never made.

Reviewed forWhich events leave from outside the root of their aggregate? Look at the aggregate code beside the event entries.

Marked guidance: a reviewer answers this question.

A setting tunes; a rule holds. An invariant filed as a setting reads as tunable, and a later operator tunes away what the model guaranteed. Keeping invariants in rules keeps what holds apart from what varies.

Reviewed forWhich setting pages hold a model invariant? Look at the settings beside the rules.

Marked guidance: a reviewer answers this question.