Domain Modeling

Overview

Build an evidence-backed domain model that gives users, specifications, code, and tests one precise language. Model the business problem and lifecycle; do not turn the result into a technical architecture or implementation plan.

Workflow

1. Read effective repository and host guidance, then inspect only the supplied requirements, existing domain docs, contracts, representative code, and tests needed to understand the named domain.
2. Run git status --short before any authorized artifact write and preserve unrelated changes.
3. Establish the modeling scope, actors, goals, in-scope scenarios, excluded scenarios, and unresolved terms.
4. Inventory candidate terms and challenge synonyms, overloaded words, implementation names, and conflicts between docs, code, and user language.
5. Identify entities, value objects, events, commands, policies, and external actors only when evidence gives each a distinct responsibility or invariant.
6. Map relationships, ownership, cardinality, identity, and lifecycle. Use a state machine when behavior depends on state or transition order.
7. Stress-test the model with normal, edge, failure, retry, cancellation, concurrency, and historical-data scenarios that are relevant to the domain.
8. Record business rules as testable statements. Separate confirmed rules, inferred rules, decisions, open questions, and contradictions.
9. Define bounded contexts and context relationships only when terminology, ownership, or consistency rules materially differ.
10. Check the model against requirements and representative code. Report drift instead of silently choosing one source as truth.
11. Return the model in the output contract. Write or update a domain artifact only when the user explicitly requests it, using the repository's existing location and format when available.