principle-boundary-discipline

边界纪律

在系统边界进行验证、类型收窄和错误处理。无条件信任内部代码。业务逻辑放在纯函数中。外壳应保持精简且只负责机械性工作。

原因： 分散的验证既冗余又嘈杂，还会造成虚假的安全感。不要把逻辑放在框架接线代码中，这样就能脱离框架进行测试。

模式：

• 在边界处（CLI 参数、配置文件、外部 API、网络协议）：进行验证、返回错误并做好防御性处理。
• 在系统内部： 使用带类型的数据，传播错误，不重复验证。信任类型。
• 跨越边界时。 暴露领域概念，而不是边界的私有表示。通用机制留在内部，专用策略放在边缘。

应用：

验证和错误处理：

• 在解析时（即边界处）验证配置，而不是在业务逻辑中验证
• 在边界处将原始数据解析为领域类型
• 不要通过公共接口重新导出传输、存储、框架或线协议类型
• 如果边界已经完成验证，就不要在调用链深处重复进行空值检查

代码组织：

• 将业务逻辑放在不依赖框架的纯函数中
• 代码审查时，标记指向外部的导入。领域或策略模块如果导入了框架、驱动程序、ORM、IO 库、生成的架构类型或适配器模块（包括仅用于类型的导入），调用方就应改为将这些值作为普通数据传入。
• 解析函数：将原始字节纯粹转换为有类型的状态
• 提示词构造：输入结构化状态，输出字符串
• 评分和评估：将状态纯粹转换为结果

测试：

• “这份数据现在是否正在跨越系统边界？”如果不是，验证就是冗余的。
• “这能否成为一个由外壳直接调用的纯函数？”如果可以，就将其提取出来。