domain-modelinglisted

# Domain Modeling ## Overview Resolve shared business language and rules from authoritative evidence. Default to terminology, ambiguity, rules, and boundary scenarios. Load lifecycle or bounded-context depth only when the business complexity actually requires it; do not turn the result into technical DDD, API, database, frontend, or backend design. ## Workflow 1. Read effective repository and host guidance, then inspect only the supplied requirements, existing business facts, representative behavior, and tests needed for the named ambiguity. 2. Fix the scope, affected actors or capabilities, authoritative facts, conflicting terms or rules, excluded questions, and the decision that downstream work needs. 3. Run the default terminology/rules pass: resolve synonyms, overloaded words, shared meanings, business constraints, and relevant normal or edge scenarios. 4. Load the **Lifecycle** profile only when states, transition order, retry, cancellation, expiry, or terminal outcomes change business meaning. 5. Load the **Bounded Context** profile only when the same term or rule has materially different meanings, owners, consistency needs, or sources of truth across boundaries. 6. Label material statements `Confirmed`, `Inferred`, `Conflict`, or `Not verified`; request a decision when a conflict changes identity, permissions, money, lifecycle, compatibility, or irreversible behavior. 7. Return only the model depth needed to unblock the request. Write or update a named domain artif