functional-modeling-with-algebraic-typeslisted

# Modeling With Algebraic Types ## Overview Two combinators build every domain model. A **product type** holds several values at once: this AND that. A **sum type**, also called a choice or union, holds exactly one of several alternatives: this OR that. Everything else, including generics and recursion, is composition of those two. Most modelling mistakes are the same mistake: using AND where the domain means OR. A record with four optional fields, three of which are set only in particular combinations, is a choice type written badly, and every consumer pays for it in checks that the compiler cannot verify. ## When to use - Designing any domain type - A record has optional fields whose presence depends on each other - Choosing between a boolean, an enum, and a union with data - A type's documentation explains which fields apply when - Reviewing types before the implementation is written Not for: enforcing value ranges on a single primitive, which is [functional-constraining-primitive-values](../functional-constraining-primitive-values/SKILL.md). ## Core rules 1. Default. **Say AND with a record, OR with a choice.** Read the requirement aloud. Every "or" in the sentence is a case; every "and" is a field. 2. Rule. **Attach data to the case that owns it.** A field that is meaningful only in one state belongs inside that state's case, not beside it. 3. Default. **Replace booleans that mean something.** A boolean carries one bit and no name. A two-case choice type