Back to Details

principle-boundary-discipline

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Boundary Discipline

边界原则

Place validation, type narrowing, and error handling at system boundaries. Trust internal code unconditionally. Business logic lives in pure functions; the shell is thin and mechanical.
Why: Scattered validation is noisy, redundant, and gives a false sense of safety. Validate data once at the boundary. Keep logic out of framework wiring so it can be tested without the framework.
The pattern:
  • At boundaries (CLI args, config files, external APIs, network protocols): validate, return errors, handle defensively.
  • Inside the system: typed data, error propagation, no re-validation. Trust the types.
Applications:
Validation and error handling:
  • Validate config at parse time (the boundary), not inside business logic
  • Store raw data at boundaries; parse lazily at use-site
  • No redundant nil checks deep in call chains if the boundary already validated
Code organization:
  • Business logic in pure functions with no framework dependencies
  • Parse functions: pure transforms from raw bytes to typed state
  • Prompt construction: structured state in, string out
  • Scoring and assessment: pure transforms from state to results
The tests:
  • "Is this data crossing a system boundary right now?" If not, validation is redundant.
  • "Can this be a pure function that the shell just calls?" If yes, extract it.
将验证、类型收窄和错误处理放在系统边界处。无条件信任内部代码。业务逻辑存于纯函数中；外层框架代码应简洁、仅做机械性处理。
原因： 分散的验证会产生冗余代码、干扰核心逻辑，还会带来虚假的安全感。在边界处一次性验证数据。将逻辑从框架配置中剥离，以便无需依赖框架即可进行测试。
模式：
  • 在边界处（CLI参数、配置文件、外部API、网络协议）：执行验证、返回错误、进行防御性处理。
  • 系统内部： 使用类型化数据、错误传播、不重复验证。信任类型系统。
应用场景：
验证与错误处理：
  • 在解析阶段（边界处）验证配置，而非在业务逻辑内部
  • 在边界处存储原始数据；在使用时再延迟解析
  • 若边界已完成验证，调用链深处无需重复进行空值检查
代码组织：
  • 业务逻辑置于无框架依赖的纯函数中
  • 解析函数：将原始字节转换为类型化状态的纯转换函数
  • 提示词构建：输入结构化状态，输出字符串
  • 评分与评估：将状态转换为结果的纯转换函数
测试要点：
  • “当前数据是否正跨越系统边界？”若否，验证即为冗余。
  • “能否将其提取为仅由外层调用的纯函数？”若是，进行提取。