先说结论：软件架构里大多数被叫成"好设计"的东西，其实在做同一件事------把模块之间的嵌套率差（|ΔN|）锁在 1。相邻层通信（|ΔN|=1）效率最高；跨层调用（|ΔN|≥2）必然衰减；而同层互调（|ΔN|=0）看起来最省事，实际是最危险的耦合陷阱------分布式单体就是这么长出来的。
这不是经验总结，是一条可以写下来的定律。下面把它推到能用的程度。
一、先看三个反复出现的现场
任何一个维护过中型系统的人，大概都撞过这三堵墙：
· 前端直连数据库。 展示层（N=0）直接查存储层（N=2），接口写得飞快，半年后字段一改，前端全线崩。补丁是一层又一层的映射代码。
· 两个微服务互相调用，调成了循环。 A 改一个字段，B 必须同步发版；B 改一个返回结构，A 跟着改。两个服务的发布窗口被迫绑定，微服务的独立性只剩名字。
· API 网关越做越厚。 它同时要处理前端格式（N=0）、业务规则（N=1）、数据模型（N=2），三层逻辑挤在一个节点里，最后没人敢动它。
传统解释是"设计缺陷""耦合没做好"。但这些词只是给症状换了名字，没给出判据------下次遇到新架构，你还是不知道该怎么判断。
二、给模块定一个嵌套率 N
把系统按"关注内容的抽象层级"分层，给每层一个整数：
· N=0 展示层：UI、交互、视觉格式。前端组件、模板、CSS。
· N=1 业务层：业务规则、流程编排、领域逻辑。Service、Use Case、Controller。
· N=2 数据层：数据模型、持久化、查询优化。Repository、ORM、数据库 Schema。
· N=3 基础设施层：架构自身的元数据。配置中心、服务注册、监控、部署。
N 不是"重要性排序"，是"这一层关心的是什么粒度的事实"。N 越大，关心的东西越接近系统自身而不是用户。
有了 N，两个模块之间的关系就能算一个数：ΔN = N(A) − N(B)。
三、架构传导效率定律
定律：模块 A 与模块 B 之间的通信效率 ∝ 1/|ΔN|。
把它拆成三种情形，工程上的直觉立刻变得可推导。
3.1 相邻层（|ΔN|=1）：最优
前端发 HTTP 请求（N=0 的格式），业务层返回 DTO（N=1 的格式）。跨度为 1，一次翻译就够，信息损耗最小。这就是分层架构真正的价值：它不只是在"分离关注点"，而是在把模块间的 |ΔN| 强制锁定为 1。
3.2 跨层（|ΔN|≥2）：衰减
前端直接读数据库：N=0 到 N=2，跨两层。前端的扁平键值对无法无损映射到规范化的关系模型------那些看起来"只是有点啰嗦"的映射代码，本质上是在补 |ΔN|=2 造成的结构性信息丢失。补得越多，说明衰减越重。
3.3 同层（|ΔN|=0）：效率最高，风险也最高
两个微服务都停在 N=1，互相直接调用。按定律，|ΔN|=0，传导效率最大------任何一方的改动 100% 传到另一方。于是所有服务必须同步部署、同步回滚、同步测试。这就是分布式单体的结构成因：它不是"微服务拆得不够细"，而是拆完之后嵌套率差消失了。
四、把四个经典模式重算一遍
同一把尺子量过去，四个被当作"最佳实践"的模式，全都指向同一个操作。
分层架构 = 强制 |ΔN|=1。 Controller → Service → Repository，每一层只与紧邻层说话。它的约束不是官僚主义，是把传导梯度锁死在最优值，同时挡住跨层衰减。
适配器模式 = 结构翻译器。 旧系统在 N=2，新模块要 N=1 的接口，直接对接就是 |ΔN|=1？不，是旧系统输出 N=2 的数据结构、新模块期待 N=1 的语义------适配器插在中间，把一次跨两层的语义跳跃拆成两次跨一层。适配器的本质是嵌套率翻译器，不是"包装一下"。
BFF = 为每种前端配一个 ΔN=1 的后端。 Web 端、移动端、IoT 端都在 N=0 附近，但各自的"结构化程度"有细微差别。一套统一 API 要么对 Web 太简单，要么对移动端太复杂------两种情况的实质都是 |ΔN| 偏大。BFF 在 N=1 的位置为每种前端单独定制，把 |ΔN| 拉回 1。
分布式单体 = |ΔN|→0 的病理状态。 纠正方案不是"再拆细"，而是在服务之间插入一层 N=1.5 的通信结构------事件总线或 API 网关。注意：这不是让耦合消失，而是把 |ΔN| 从 0 拉开到 0.5～1，引入健康的传导摩擦，让改动不再 100% 瞬时分发。
五、三条能落地的设计原则
原则一：保持 |ΔN|=1 的模块梯度。 每一层只与紧邻层通信。为了"方便"让前端直连数据库，省下的是今天的代码量，欠下的是 |ΔN|=2 的系统性衰减，利息按维护次数复利计算。
原则二：跨层需求 = 引入适配层。 如果 N=0 的模块确实需要 N=2 的数据，不要跨两层调用，在中间放一个 N=1 的适配层（Adapter 或 BFF）。适配层承担的是翻译成本，而这个成本原本也会以更难查的形式出现------在业务代码的每个角落里。
原则三：把 |ΔN| 分布纳入监控。 架构里所有模块对的 |ΔN| 应该集中在 1 附近。跨层调用（|ΔN|≥2）触发架构评审；同层密集互调（|ΔN|→0）是分布式单体的早期预警。这一条比任何"架构规范文档"都可执行，因为它是一个可以算出来的数。
六、五分钟自查清单
不用画图，打开代码库就能做：
· 列出所有跨模块调用，标出调用方与被调方的层级（N 值）。
· 统计 |ΔN|≥2 的调用点数量。超过 10 个，说明架构已经在付衰减税。
· 找"双向调用"的服务对。存在即 |ΔN|=0 风险，先看它们的发布是否已被迫绑定。
· 看网关或 BFF 的代码行数增长曲线。它膨胀的速度，等于上游 |ΔN| 失配的速度。
· 检查映射代码（DTO 转换、字段拼装）占比。它高，不一定是程序员啰嗦，多半是 |ΔN| 太大。
七、三个可能的反驳
"异步消息不就解耦了吗？" 消息总线把同步调用换成异步事件，但消息契约本身就是一层新的语义------总线大致落在 N=1.5。|ΔN| 没有消失，只是从 0 拉到 0.5，并且把翻译成本从调用栈转移到了契约设计上。这也是为什么"消息格式一改，全链路炸"的事故并不比同步调用少。
"性能要求必须跨层怎么办？" 那就跨，但要显式承认衰减：缓存一致性、字段映射、错误语义转换，这些成本必须记在架构账上，而不是散落在业务代码里假装不存在。可观测的衰减，比隐藏的衰减便宜。
"这不就是常识吗？" 常识是清单：分层、解耦、单一职责。清单在熟悉的场景里好用，遇到 Serverless、边缘计算、Service Mesh 这些新结构就失效------没人告诉你边缘函数的 N 是几。定律是判据：先定 N，再算 ΔN，结论自己出来。
八、它统摄的不是一个新范式
结构计算机科学不打算发明第五种编程范式。它是把已有范式的底层动作翻译成同一个数学表达：
· OOP：封装 = 隔离嵌套率；接口 = 定义 |ΔN|=1 的通信契约。
· 函数式：纯函数 = 自完备模块；组合 = 构造 |ΔN|=1 的传导管道。
· DDD：限界上下文 = 为子领域定义独立嵌套率；上下文映射 = 定义跨 ΔN 的翻译策略。
· CQRS：写（N=1）与读（N=0）分道 = 为不同嵌套率的操作配专用通道。
一句话收束：一切好的架构，都是把 |ΔN| 降到 1 的操作；一切难维护的架构，都能找到一处 |ΔN| 失控。
软件架构是结构的显式编码。它天然服从结构定律，只是过去我们把它叫成了"经验"。
作者：林小黑 2026-10-23
（本文出自林小黑的"结构认知"系列，首发于"今晚狗蛋看局"。更多用结构学重新理解世界的内容，见 gitee.com/samforce/structural-cognition。）