Boundary Discipline（边界纪律）是一条用于组织验证、错误处理与框架适配代码的设计原则。它关注的不是某个具体工具的实现，而是代码中校验与业务逻辑应当放在哪里。资料给出的总原则是：把验证、类型收窄和错误处理放在系统边界上，在系统内部无条件信任已有数据；业务逻辑放在纯函数中，外壳保持轻薄且机械。
一、用途 该原则适用于为代码接线验证、错误处理或框架适配器的场景，目标是把校验集中在真正需要它的位置，避免校验逻辑散落各处带来的噪音、冗余和虚假安全感，同时让核心逻辑脱离框架依赖，从而可以不依赖框架进行测试。
二、主要能力与模式 资料将模式拆为三层。
- 边界层：包括命令行参数、配置文件、外部 API、网络协议。在这一层做校验、返回错误、进行防御性处理。
- 系统内部：使用带类型的数据，让错误向上传播，不做重复校验，信任类型。
- 跨边界处：暴露领域概念，而不是边界自身的私有表示；把通用机制保留在内部，把特殊用途的策略放在边缘。
三、使用方式（资料给出的应用示例） 验证与错误处理方面：在解析时校验配置，也就是在边界处校验，而不是在业务逻辑内部校验；在边界处把原始数据解析为领域类型；不要通过公开接口再导出传输、存储、框架或协议（wire）类型；如果边界已经校验过，就不要在调用链深处做冗余的空值检查。 代码组织方面：业务逻辑置于不依赖框架的纯函数中；解析函数是从原始字节到类型化状态的纯转换；提示构造是结构化状态输入、字符串输出；评分与评估是从状态到结果的纯转换。 资料还给出两个自检问题：第一，这份数据此刻是否正在跨越系统边界？如果不是，那么校验就是冗余的。第二，这能否成为一个由外壳直接调用的纯函数？如果可以，就把它抽出来。
四、适用场景 适合需要在项目或团队中统一约定“在哪里校验、在哪里信任”的开发与设计工作，尤其是同时存在命令行、配置文件、网络请求、外部 API 等多种入口，并且希望业务逻辑可独立测试的代码库。
五、限制 该资料为原则性说明，未提供安装命令、依赖、支持的语言或框架、收费与价格、效果数据等信息，这些内容暂未提供。