domain-modelinglisted

# Domain Modeling ## Iron Law `ILLEGAL STATES MUST BE UNREPRESENTABLE IN THE DOMAIN CORE.` If the type or data shape permits a state the domain forbids, a future caller will construct it. Make the state impossible to express rather than guarding against it. ## When to Use - Data shape affects correctness: domain data, fields, states, statuses, allowed combinations, transitions, validation boundaries, value objects, functional cores, or effect isolation. - The next important step is shaping feature or domain data before implementation. - Reviewing code where I/O, mutation, and business rules are coupled. ## When NOT to Use - Public HTTP contract details; use `api`. - Database physical schema, indexes, or migrations; use `database`. - Module organization, layering, DDD tactical patterns; use `architecture`. - Broad refactoring sequence; use `refactoring`. ## Core Ideas 1. Decide data shapes and invariants before writing transformations. 2. Distinguish identity, state, value, and time. Prefer immutable records, sums, and maps. Treat classes that wrap pure functions as modules; avoid classes that bundle behavior with mutable state. 3. Split code into data, calculations, and actions; maximize data/calculations and minimize actions. 4. Parse at boundaries into trusted internal shapes; do not pass raw external data inward. Where the language has a dominant, mature schema/validation library (Pydantic in Python, Zod in TypeScript), parse with it rather th