domain-modelinglisted

# Domain Modeling ## Purpose Use this skill to turn business requirements into an explicit domain model before implementation. It is framework-neutral and should not assume jfoundry, Spring, .NET, Go, Python, or any specific architecture style. Do not treat domain modeling notes as ceremony for simple CRUD changes. Use them when a change introduces business rules, lifecycle state, invariants, domain events, cross-aggregate coordination, or ambiguous domain language. ## Core Workflow 1. Start from business workflows, not tables or controllers. 2. Extract language, commands, events, rules, states, exceptions, and external actors. 3. Identify bounded-context candidates when terms or rules change meaning across workflows. 4. Design aggregates around invariants and consistency boundaries. 5. Produce the modeling output protocol before coding. 6. Review for table-driven modeling, anemic behavior, oversized aggregates, and misplaced orchestration. ## Reference Routing - Read `references/input-analysis.md` when starting from requirements, user stories, tickets, existing tables, APIs, or code. - Read `references/event-storming.md` when workflows are complex, event-heavy, or involve policies and external systems. - Read `references/bounded-contexts.md` when terms, ownership, data, or rules may differ across teams or subdomains. - Read `references/aggregate-design.md` when choosing aggregate roots, entities, value objects, invariants, repositories, or domain services. - Read `ref