第二部分 设计
把 Unix 原则推进到模块、协议、进程、语言、配置、接口与复杂度的具体设计。
学习目标
- 能解释 第二部分 设计 如何回答“从一项模糊需求推导可组合、可诊断、可替换的系统结构”
- 能沿 模块边界 → 数据表示 → 进程组合 → 用户接口 → 复杂度预算 重建输入、状态、输出和失败边界
- 能使用 design_quality = boundaries × representations × observability × restraint 比较正常输入、恰好边界与单点故障
- 能画出设计决策依赖图并标出每项决定的撤回条件
为什么要从这个问题开始
把 Unix 原则推进到模块、协议、进程、语言、配置、接口与复杂度的具体设计。 设计部分按边界、表示、可见性、组合方式和复杂度预算逐层收敛方案；每一章提供不同的分解工具，但都必须回到接口与失败合同。 在本课程中，Unix 风格只是一组待验证假设；当延迟、安全、事务一致性、团队能力或平台约束改变时，允许用证据拒绝它。
直觉、对象与计算合同
贯穿场景是：从一项模糊需求推导可组合、可诊断、可替换的系统结构。先固定输入版本、资源预算和成功条件，再观察 正交性、故障可见 与 必要复杂度；若中途改了数据或口径，结果作废。
这个式子用于公开变量关系，不冒充经验常数。任何抽象若不能减少调用者需要同时理解的状态，就不应继续叠加。 需要特别防范的失败是：先选工具和框架，再用原则为既定方案寻找理由。
↡第二部分 设计在第二部分 设计中对应模块边界的可复核状态。· ↡正交性在第二部分 设计中对应数据表示的可复核状态。 ·
↡文本协议在第二部分 设计中对应进程组合的可复核状态。·
↡故障可见在第二部分 设计中对应用户接口的可复核状态。·
↡最小惊讶在第二部分 设计中对应复杂度预算的可复核状态。·
↡必要复杂度在第二部分 设计中对应模块边界的可复核状态。正式目录节点：解释与验证
下面逐项保留作者送印版目录坐标。每一项都放回 第二部分 设计 的机制链解释，并在页面实验组件与章末复核清单中再次出现；标题出现本身不计作覆盖。
II. Design
“II. Design”把本单元的总机制细化为一个可定位的主题坐标。 在“设计部分按边界、表示、可见性、组合方式和复杂度预算逐层收敛方案；每一章提供不同的分解工具，但都必须回到接口与失败合同。”这条因果链中，本节点重点检查正交性：先写预期，再改变一个直接条件，并用任何抽象若不能减少调用者需要同时理解的状态，就不应继续叠加。作为停止或继续的边界。
三视图实验：先预测，再操作
1. 组合拓扑
沿 模块边界 → 数据表示 → 进程组合 → 用户接口 → 复杂度预算 定位职责和失败传播，只允许改变一个直接条件。
taoup-part-02 · 组合拓扑
第二部分 设计
从一项模糊需求推导可组合、可诊断、可替换的系统结构
选择验证情境
选择工程动作
正常路径和责任链一致，可以进入下一节点，但仍须保存可重放记录。
职责、接口与失败传播
II. Design
常见误区
术语
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 第二部分 设计
正交性的检查入口；必须能回到输入、状态与失败证据。
- 正交性
文本协议的检查入口；必须能回到输入、状态与失败证据。
- 文本协议
故障可见的检查入口；必须能回到输入、状态与失败证据。
- 故障可见
最小惊讶的检查入口；必须能回到输入、状态与失败证据。
- 最小惊讶
必要复杂度的检查入口；必须能回到输入、状态与失败证据。
- 必要复杂度
正交性的检查入口；必须能回到输入、状态与失败证据。
练习与答案
练习
- 问题 1：目录证据复核。 选择三个相邻目录节点，说明它们在 第二部分 设计 中的因果关系，并指出各自的实验与练习证据。
- 问题 2：故障诊断。 在“从一项模糊需求推导可组合、可诊断、可替换的系统结构”中注入“先选工具和框架，再用原则为既定方案寻找理由”，第一处应该拒绝结果的位置在哪里？
- 问题 3：方案判断。 什么情况下应该拒绝本章首选的 Unix 风格方案？
本章小结
第二部分 设计 的核心不是记住目录名，而是用 模块边界、数据表示、进程组合、用户接口、复杂度预算 把 正交性、文本协议、故障可见、最小惊讶、必要复杂度 连成一条可反驳、可重放、可撤回的证据链。最终验收是：能画出设计决策依赖图并标出每项决定的撤回条件。