建模先于代码

回答的问题：代码该长成什么形状。偏函数是「不是对所有输入都有定义的函数」，例如「关闭会话」只在会话打开时有定义。全化是把剩下的情况也定下来：会话已关闭时再关一次，答「已关闭」，不报错也不崩。模型定义的是实现的形状，所以它排在代码之前。

三句动作

1. 把状态和操作写成偏函数：每个操作在哪些前置状态下有定义。 状态名与操作名取自统一语言。
2. 全化：定义域之外的每一格给一个确定的答复。 答复是拒绝、幂等返回或显式错误。不变式排除的格写「不可达」，不处理。全化之后实现里不再有「不该发生」的分支。
3. 翻成领域模型和对象模型再写代码。 概念与边界按领域建模，对象怎样协作按 SOLID，名字取自统一语言。代码里的每个类型能指回模型。

全化表说的是什么必须成立，不是代码该长成什么样。照着它直接写，得到一个按状态分支的大函数，对但难维护；翻成领域模型与对象模型，对的东西才写得简洁、能维护。

各类工作里怎么用

写在哪

不新开文档。全化表写在细化设计清单的「全化表」一节，或切片开工包的「全化表」一行；不碰状态写「不涉及状态」。领域模型与对象模型写在细化设计的领域模型与关系模型、开工包的领域模型与对象模型。全化表碰到状态与操作就做，不需要人确认。

什么时候必须重做

• 实现里出现「不该发生」「理论上不会」的分支或注释。
• 加了一个状态或一个操作。
• 一个函数按状态写了一长串分支。
• 一个类型说不出它指回模型的哪一部分。
• 同一个状态判断在几处各写了一遍。

相邻的模型

think-ought-vs-is：这件事的工作到底是什么。think-orthogonal：这个问题的空间怎么拆。think-right-then-well：按什么顺序建，怎样算好。think-evidence：怎么知道它是真的。think-closed-loop：这件事该由谁做，一次做多大，多久看一次。think-unknowns：没说清的地方，凭什么定。

主线：慢即是快。回到上层：全部思维模型的表、放在一件事上的次序与整条流的顺序，在入口技能 single-session-dev-flow；按场景做事从总入口 pqw-mode 进。