principle-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. 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.
-
Across the boundary. Expose domain concepts, not the boundary’s private representation. Keep general-purpose mechanism inside and special-purpose policy at the edge.
-
在边界(CLI 参数、配置文件、外部 API、网络协议):校验、返回错误、防御性处理。
-
系统内部: 类型化数据、错误传播、不再校验。信任类型。
-
跨过边界。 暴露领域概念,不是边界的私有表示。通用机制放里面,特化策略放边缘。
Applications:
应用:
Validation and error handling:
校验与错误处理:
-
Validate config at parse time (the boundary), not inside business logic
-
Parse raw data into domain types at the boundary
-
Do not re-export transport, storage, framework, or wire types through the public surface
-
No redundant nil checks deep in call chains if the boundary already validated
-
在解析时(边界)校验配置,别在业务逻辑里
-
在边界把原始数据解析成领域类型
-
别通过公开面再导出传输、存储、框架或 wire 类型
-
边界已校验过,调用链深处别再塞冗余 nil 检查
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
-
业务逻辑放无框架依赖的纯函数
-
解析函数:原始字节到类型化状态的纯变换
-
Prompt 构造:结构化状态进,字符串出
-
打分与评估:状态到结果的纯变换
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.
-
「这份数据此刻正在跨系统边界吗?」不是,校验就多余。
-
「这能做成外壳只管调用的纯函数吗?」能,就抽出来。