principle-model-the-domain

Identify the lifecycle phases the booleans represent and encode them as explicit states in a state machine. This makes invalid state combinations unrepresentable and deletes the branches that kept the booleans in sync.

Model the domain when a new feature grows an existing if/else chain, when a second boolean must stay in sync with a first, or when shape assumptions repeat across files. These are tells that the domain is scattered rather than encoded.

Use a map, registry, lookup table, or discriminated union to gather branching into one structure. A reducer or command/event model works for ad hoc state mutations, and a module organized around one body of domain knowledge replaces phase-based decomposition.

Avoid the abstraction when the current shape is already clear, local, and unlikely to grow. Be skeptical of any structure that adds indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.

Phase-named modules organized around load, validate, transform, and save repeat the same domain rules across steps. Execution order is not ownership, so modules should be organized around one body of domain knowledge instead.