| name | domain-modeling |
| description | Resolve unclear business meaning, invariants, consistency ownership, or bounded-context boundaries. Use only while one of those domain decisions remains material; skip technical module reorganization, generic architecture, CRUD, utilities, and styling. |
Domain Modeling
- Confirm that business meaning, invariants, consistency ownership, or bounded-context boundaries are materially unclear. Keep technical module reorganization and generic architecture outside this workflow.
- Read existing domain documents, decisions, tests, workflows, and relevant code. Identify the domain authority and mark unknowns instead of inventing business rules.
- Collect representative success, failure, and edge scenarios. Resolve synonyms, overloaded terms, and meanings that differ by actor or context. Use the agreed language in models and code.
- Extract business rules and invariants. Assign each invariant an owner and a consistency boundary, then challenge it against the scenarios and current implementation.
- Read ddd-reference.md. Introduce subdomains, bounded contexts, context mappings, entities, value objects, aggregates, services, or events only when a concrete difference in meaning, ownership, lifecycle, or consistency requires them.
- Read aggregate-design.md before defining or changing an aggregate. Do not equate a bounded context with a service or an aggregate with an object graph.
- Validate the model by walking every representative scenario with the user or an authoritative source. Record stable language and justified decisions using artifact-formats.md; keep unresolved questions explicit.
Finish when terms are unambiguous within each context, invariants have enforcement boundaries, cross-context translations are explicit where needed, and every technical pattern has a domain reason.
