写有状态逻辑或分支/形状假设散落时，用领域结构替代条件判断

当代码有状态、分支很多或跨文件重复同一形状假设时，把领域建模成结构以消除散落条件并使无效状态不可表示。

适用场景

解决思路

1. 把真实领域编码到一个数据结构中，而不是把领域规则散落在各处的条件判断里。
2. 编写有状态逻辑时，在写代码的当下就选择匹配领域的结构；不要等到以后当重构再做，因为后期恢复成本高且会被推迟。
3. 用状态机替代散落的布尔值、阶段变量或生命周期检查。
4. 用有类型对象/模型替代松散参数或重复出现的形状假设。
5. 用 map、registry、查找表或 discriminated union（可辨识联合）替代散布在多个文件中的分支。
6. 用 reducer 或 command/event 模型替代临时性的状态修改。
7. 按一组领域知识来组织模块，而不是按 load、validate、transform、save 这类执行顺序来组织；执行顺序不代表所有权。
8. 建立一个小模块边界，把重复行为、所有权或不变量收拢到一起。
9. 当数据访问模式需要时，使用 queue、cache、index、graph/tree 或规范化集合。
10. 使用其他任何合适的结构；如果都不合适，先明确代码绝不能允许什么，以及数据会如何被读取，再找到能精确编码这些约束的结构。

适用边界 · 注意事项

• 当前代码形状已经清晰、局部且不太可能增长时，不要强行抽象；优先写 boring code。
• 当抽象只增加间接层，却没有消除分支、重复规则、无效状态或生命周期风险时，不要采用该抽象。
• 不要按 load、validate、transform、save 这类执行阶段或 temporal decomposition 来组织模块；如果这么做会让同一领域规则在多个步骤中重复，就不适用。