为什么我们在软件中衡量一切，却忽视最重要的那件事

Source: Dev.to

（请提供需要翻译的正文内容，我才能为您进行简体中文翻译。）

缺失的质量维度：业务契合度

业务软件的存在是为了表示、强制执行并演进业务规则。它的首要职责不是技术卓越，而是随时间保持语义正确——我们可以称之为 业务契合度。

一个具备强大业务契合度的系统不仅仅是映射当下的需求；它会使领域变得明确且可组合。新功能可以在几乎不需要重构的情况下插入。意想不到的能力往往自然地从模型结构本身中涌现——不是通过过度工程，而是因为正确的概念位于正确的位置。

以处理资金转账的合规系统为例。若将理由记录为自由文本，你只能得到一段脆弱的字符串来搜索。若将转账关联到具有明确金额和条款的结构化租赁协议，瞬间就能实现自动对账、差异检测以及更丰富的审计轨迹——这些功能既不是开发者也不是业务利益相关者明确提出的，却直接源自模型。

业务契合度体现在以下问题上：

• 系统是否准确地表示了业务领域？
• 业务规则是 结构化 强制执行，还是过程化执行？
• 当业务发生变化或扩展时，系统是否能够在局部进行少量摩擦的适配，还是需要全局重构？
• 模型是揭示约束和可能性，还是将其掩盖？

这些问题决定了长期成本、风险、可维护性——以及系统持续演进和意外强大能力的潜力。然而，它们在质量讨论中几乎完全缺席。

为什么？ 因为业务契合度难以量化。

为什么业务契合度无法量化

业务契合度因结构性原因而难以量化：

• 它是语义层面的，而非技术层面的。
• 它是情境性的，而非绝对的。
• 随着业务的演进而演变。
• 需要理解，而不是单纯观察。

没有相应的度量指标：

• “这个概念是否属于此处？”
• “这条规则是内在的还是偶然的？”
• “这个模型是否仍然与现实保持一致？”

任何对业务契合度的测量尝试都会沦为使用代理指标，而代理指标不可避免地会漂移。因此，团队往往只测量那些可以直接测量的内容。

指标是替代方案，而非解决方案

在缺乏评估业务契合度的方法时，软件开发文化往往倾向于技术指标：

• 测试覆盖率
• 构建健康度
• 开发速度
• 静态分析
• 可靠性指标

这些指标并没有错；它们只是正交的。

它们回答的是：“系统是否在运行？”

它们不回答：“系统在业务表示上是否正确？”

指标填补了缺乏语义质量工具所留下的真空，但它们并不能取代该工具。

领域模型的作用

问题在于度量衡量的是语言的使用——但它们并未检验所讲述的故事是否正确。

相反，丰富的领域模型是业务领域的表现——即故事本身。

模型并不直接衡量适配度，但它做了一件更重要的事：使业务适配度可评估。

领域模型：

• 将业务概念明确化
• 集中管理规则和不变式
• 将行为附着于意义
• 提供一个稳定的检查对象

这实现了任何度量都无法实现的功能：业务验证。

业务专家可以查看领域模型并说：

• “这不对。”
• “缺少了这个。”
• “这与现实不符。”

这不是主观臆断，而是针对真相来源的验证。没有领域模型，这种对话是不可能的。

本地化：了解何时何地发生什么

强大的领域模型提供了扎实的上下文。它告诉你：

• 什么存在
• 逻辑位于何处
• 哪些规则适用于哪些概念

这种本地化显著降低了变更成本。当规则发生变化时，你能够准确知道需要在何处进行修改。

在逻辑位于服务、管道或流中的系统里：

• 含义分散
• 规则重复
• 所有权不明确
• 变更变成考古

领域模型不是负担——它是定位基础设施。

地图类比

领域模型对软件而言，就像地图对城市的作用。

在一个小村庄里，你可以不依赖地图进行导航；所有信息都可以记在脑海中。随着城市的扩张，方向感就变得必不可少。

没有模型，开发者在大型系统中导航的方式就像游客在陌生城市里没有地图一样：

• 通过反复试错
• 依靠过去路径的记忆
• 一次又一次地提出相同的问题

你可以前进。你可以交付。但你永远没有方向感。

法拉利问题

如果从不评估业务匹配会怎样？

没有东西会立刻崩溃。系统仍在运行。测试通过。发布顺利。指标看起来健康。

这就是问题持续存在的原因。

这就像用法拉利 F40 去犁地：

• 它会动
• 它动力强大
• 它外观令人印象深刻

但它：

• 与任务严重不匹配
• 在负载下脆弱
• 维护成本高昂
• 实际犁地效果差

工作仍然完成——但代价极其高昂。

隐形拖拉机

…（原文在此处突然结束；如有需要请继续讨论）。

更深层的问题：没有明显的对比

大多数团队从未见过一个与业务高度契合的系统随时间演进。

如果从未见过拖拉机耕地，那么法拉利看起来似乎是一个合理的选择。

一个契合度高、模型驱动的系统

• 静默地变化
• 需要更少的人力
• 产生的戏剧性更少
• 不会产生英雄故事

它看起来并不令人印象深刻——除非你在乎农业。

在缺乏对比的情况下，低效与必要性变得难以区分。

真正的结论

大多数软件系统 并未 衡量业务契合度。更重要的是：它们做不到。

没有丰富的领域模型，就没有可供评估业务正确性的有形工件。质量只能从代理指标推断。正确性只能假设。

令人不安的事实是：

业务软件最重要的质量属性既没有被衡量，也无法衡量。领域模型 并不 量化业务契合度——它使其可见、可讨论、可纠正。

这也是它被忽视的原因。

并不是因为它不重要——而是因为没有领域模型，业务契合度不仅未被衡量，而且是不可知的。