别再乱丢String，领域错误分层启动了？

Zui近我在 Pico-CRM 里开始把“领域错误”单独拎出来先Zuo一个Zui小三层：

return Err);

这里的关键点是：错误聚焦在字段格式，不牵扯业务规则。

比如 Contact 的 verify 现在还是这种风格：

比如手机号筛选条件不是合法手机号：

Pico-CRM 这次Zuo“领域错误三层体系”，本质上不是在发明什么复杂框架，而是在解决一个hen土但hen痛的问题：别让错误消息继续散落成一地字符串。

这里不Neng吹过头，因为仓库现状就是“Yi经开始收口，但还没彻底Zuo完”。

它们dou叫 validation，没错；但Ru果不再往下分，应用层Zui后还是只Neng继续Zuo字符串匹配。

所以我后来换了一个思路：不是先追求一个大而全的错误系统，而是先把Zui常见的三类领域错误收口。

pub enum ValidationError { InvalidFormat { field: String, reason: String }, BusinessRule { rule: String, details: String }, MissingField,}

我当时拆这三个，不是为了学术好kan，而是因为它们刚好对应后台业务里Zui常见的三种失败。

创建规约时先Zuo校验：

我后来不太满意这种Zuo法。因为“验证失败”这个词太大了。

因为以前Ru果每个应用服务、每个 server function、每个页面dou自己拼文案，Zui后一定会出现：