A data model makes a system’s information, relationships, units, and constraints visible in the structure of the code. Clear models put data first, allowing behavior to organize itself around meaningful concepts instead of hiding intent behind generic fields, methods, and boilerplate. section 4.0 section 4.4
Make ambiguous values carry their meaning
A constructor such as `new User("John", 180, 70)` leaves the numeric values and their units unclear. A model such as `PhysicalProfile("John", WeightInPounds(180), HeightInInches(70))` names the domain concepts, documents the units at the call site, and prevents arguments from being accidentally reversed. Extra types add protection when ambiguity or risk justifies their cost; they become harmful when they obscure a simple value. section 4.0
Shape a model around the data that actually drives behavior:
- Name domain concepts explicitly rather than representing them with unexplained primitives. section 4.3
- Keep units, categories, identity, state, ranges, and invariants close to the values they describe. section 4.3
- Prefer small immutable data carriers when mutation is unnecessary, and flatten structures that hide meaning. section 4.4
- Avoid over-modeling: introduce a type only when it adds clarity, protection, or a meaningful rule. section 4.0 section 4.3
Before making changes, identify the data the code is really manipulating. Ask: - What is the central data concept? - Which values represent identity, state, unit, range, or category? - Which values come from outside the system, and which are internal? - Which values are temporary, derived, or persisted? - Which values drive behavior? - Which values naturally belong together? - Which values are part of a public contract or generated model that cannot be changed directly?
Use the data-model inspection prompts to identify central concepts, value roles, boundaries, persistence, and behavior-driving data before refactoring. section 4.3
