74.1 康威定律及其逆定律
一句话
系统架构必然长成组织沟通结构的影子——因为模块边界就是协商边界；逆定律是唯一的主动招式：先画出想要的架构，再把团队边界改成它的形状。
原始表述与它真正的分量
Melvin Conway 1968 年发表于《How Do Committees Invent?》：
“Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”
设计系统的组织，受限于其产出的设计必然是这些组织沟通结构的副本。
关键词不是 “倾向于”，是 constrained to (被迫)。这不是管理建议，是被反复验证的结构性约束：
| 观察到的组织形状 | 长出来的系统形状 |
|---|---|
| 前端组 / 后端组 / DBA 组 | 严格分层架构，交接处是交付瓶颈 |
| 三个团队分别管订单、库存、支付 | 三个服务，边界恰好是三个团队的边界 |
| 一个大团队管全部 | 单体（这未必是坏事） |
| 每个团队都自建一套工具 | 内部重复建设，成本 × 团队数 |
| 两个团队共管一个服务 | 变更排队、发布协调会、谁都不敢重构 |
为什么是 “被迫”：三个机制
- **接口即合同，合同靠协商。**两个模块之间的接口，必须由能直接对话的人谈出来。跨团队谈不出来的接口，最终会退化成 “各自实现一份” 或者 “共享数据库”。
- **信息跨边界衰减。**每经过一次转述，需求与约束都会丢细节。团队边界越多，系统里 “对齐成本” 的代码就越多 (防腐层、数据同步、兼容逻辑)。
- **局部理性。**每个团队的 KPI 是自己的交付速度，于是优化都会落在 “让自己边界内的事变简单”——边界就自然长在自己的舒适区，而不是业务需要的地方。
🔑 康威定律不是在描述 “架构应该怎样”，而是在描述 “架构一定会怎样”。忽视它，你设计的架构会在 6–18 个月里被组织慢慢改回它本来的形状。
沟通路径数：为什么团队不能太大
全连接沟通路径 = n(n-1)/2
| 团队规模 | 沟通路径数 | 现实感受 |
|---|---|---|
| 5 人 | 10 | 面对面能同步 |
| 8 人 | 28 | 开始需要例会 |
| 10 人 | 45 | 需要文档与流程 |
| 20 人 | 190 | 靠流程和层级，信息严重失真 |
| 50 人 | 1225 | 只能靠架构与接口替代沟通 |
| 100 人 | 4950 | 必须有部门墙 |
结论直接指向架构：组织规模每翻倍，沟通路径涨 4 倍。当沟通成本超过写代码的成本时，唯一的出路是用明确的模块边界 / 接口契约替代口头沟通——这正是 “架构” 的起源。
逆康威定律 (Inverse Conway Maneuver)
定义：主动调整组织结构，让期望的架构成为 “自然产物”，而不是等它自然长歪。
执行顺序 (顺序反了会失败)：
① 目标架构（画 C2 容器图：想要哪几个服务、谁依赖谁）
↓
② 团队边界（每个服务一个 owner 团队，一对一）
↓
③ 依赖方向（服务依赖 = 团队依赖；被依赖方要能被依赖方「要求」）
↓
④ 所有权（代码库、发布权、on-call、SLO 都归 owner）
↓
⑤ 平台能力（把重复建设的部分收编成平台团队）
| 步骤 | 具体动作 | 判据 |
|---|---|---|
| ① 目标架构 | 先画目标状态的容器图（80.2 架构图规范） | 元素 ≤ 12，每个容器一句话职责 |
| ② 团队边界 | 一个容器一个团队（Team Topologies 四类，见 74.2 四种团队类型，待补） | 团队能独立发布该服务 |
| ③ 依赖方向 | 让「被依赖」的团队先成为平台团队 | 依赖方不需要开协调会 |
| ④ 所有权 | 服务目录里 owner 字段唯一 | on-call 轮值表唯一 |
| ⑤ 平台能力 | 日志、发布、监控、脚手架收编 | 新服务 1 天内能上线 |
💡 逆定律最常见的失败方式：只重组团队，不转移所有权。团队名字改了，代码库、发布权限、on-call 还在原团队手里，架构一点没变——组织图变了，康威定律照旧生效。
用案例说话
| 组织动作 | 架构结果 | 时间尺度 |
|---|---|---|
| Amazon 推行「两个披萨团队」+ 强制 API 化 | 服务化 + 内部 API 经济 | 2–3 年 |
| Netflix 按流媒体域重组，每个域全栈 | 数百个微服务，团队自治理 | 3 年 |
| 银行按「业务能力」重组（账户 / 支付 / 风控） | 从大核心系统拆出业务中台 | 2–4 年 |
| 一家公司原地不动，只下「拆微服务」的命令 | 拆完仍是分布式单体（30.3 分布式单体反模式） | 6–12 个月后回滚 |
| 两个团队合并成一个 | 两个服务半年内被合并或共享数据库 | 6–12 个月 |
最后两行是同一枚硬币：组织不动，架构白拆；组织一合，架构必合。
错配的症状表：拿它做诊断
| 症状 | 组织病因 | 架构后果 |
|---|---|---|
| 一个团队维护 12 个服务 | 认知负荷超载（健康值：每人 1–2 个服务） | 谁都不熟，改 A 崩 B |
| 一个服务被 5 个团队修改 | 无明确 owner | 变更排队、发布协调会、谁都不重构 |
| 每次发版都要跨 3 个团队开会 | 接口未契约化，或依赖方向错了 | 交付周期 = 会议周期 |
| 每个团队都有一套 CI / 日志 / 网关 | 缺平台团队 | 重复建设，成本 × N |
| 业务需求总要「协调多个团队」才能上线 | 边界按技术分层，不按业务能力 | 交付周期以月计 |
| 数据库被 6 个服务共享 | 边界没画清（32.6 共享数据库反模式） | 谁都不敢改表 |
| 重构提案永远排不上优先级 | 没有架构治理与决策机制（58.1 ADR 实践 / 58.3 架构评审） | 技术债持续累积 |
怎么把它用在日常决策里
| 你想得到 | 组织上该做 | 反面例子 |
|---|---|---|
| 微服务化 | 按业务能力建全栈小团队，每队拥有 1–3 个服务 | 先拆 40 个服务，团队不动 |
| 模块化单体 | 一个大团队 + 明确的模块 owner | 拆成 5 个团队共管一个单体 |
| 平台化 | 建平台团队，把重复建设收编 | 让每个业务团队「顺便」维护平台 |
| 快速集成 | 把两个系统放进同一团队或同一部落 | 靠每周对齐会维持集成 |
| 统一技术栈 | 技术委员会 + 平台团队落地 | 发一份规范文档，无落地机制 |
代价：逆定律不是免费的重构
| 代价 | 量级 | 说明 |
|---|---|---|
| 重组期生产力下降 | 10%–20%，持续 1–2 个季度 | 招聘、交接、新协作模式磨合 |
| 见效周期 | 2 个季度（边界清晰）→ 1 年（行为习惯） | 架构图很快改，人的协作习惯很慢 |
| 知识流失风险 | 核心成员流失率短期上升 | 重组常伴随离职 |
| 频繁重组的伤害 | 每次重组都要付一次成本 | 一年一改 = 组织抖动，比错误架构更伤 |
⚠️ 技术约束无法靠组织解决：合规要求、遗留系统、只能有一个的共享数据库，不会因为团队重组而消失。逆定律改变的是 “人怎么协作”，不是 “物理定律”。
反模式
| 反模式 | 后果 |
|---|---|
| 只改架构图，不动团队 | 6–18 个月后架构被组织改回原形 |
| 只重组团队，不转移所有权 | 组织图变了，交付边界没变；康威定律照旧生效 |
| 按技术分层分团队（前端组 / 后端组 / DBA 组） | 分层架构 + 交接瓶颈，交付周期被拉长 |
| 按服务数量分团队（一人一服务） | 认知负荷与协调成本反向爆炸，服务水平下降 |
| 先拆微服务，再「以后补团队」 | 分布式单体，跨服务事务遍地，回滚成本极高 |
| 两个团队共管一个服务 | 变更冲突、责任真空、谁都不敢重构 |
| 一年重组三次 | 组织抖动，交付能力持续低位 |
| 用「架构委员会」代替所有权 | 决策权与交付责任分离，架构评审变成盖章 |
自检
Q1 公司决定 “明年做微服务改造”，但团队仍是前端组、后端组、DBA 组三个职能团队。按康威定律，一年后最可能出现什么？为什么？
▸ 答案：出现分层架构 + 服务外壳的混合体：按职能分的团队只能在自己的职能边界内画边界，于是 “服务” 被切成 “前端服务 / 后端服务 / 数据库服务”，跨服务的每次改动仍要走三层交接。更常见的结果是拆完之后又合并回去，或者退化成共享数据库的分布式单体。根因是：服务边界必须与团队边界同构；团队没变，服务边界就只能沿职能线切，而职能线恰好是交付最慢的方向。
Q2 逆康威定律听起来是 “先改组织，架构自然就对”。它最容易在哪一步失效？
▸ 答案：在第 ④ 步 “所有权” 失效。改组织结构 (改名、换汇报线) 是几周的事，但代码库归属、发布权限、on-call 责任、SLO 指标如果仍留在原团队，新团队就没有真正的决策权，遇到跨团队问题还是会回去找原团队拍板——沟通结构没变，架构就不会变。判定方法很硬：**新团队能不能在没有任何人审批的情况下，把这个服务发布到生产？**不能，就说明所有权没转移。
Q3 一个 8 人团队维护 12 个微服务，成员抱怨 “每次上线都怕”。这违反的是康威定律还是别的东西？
▸ 答案：这不是康威定律被违反，而是认知负荷超过了团队容量 (74.4)。康威定律说的是 “架构反映沟通结构”，这里沟通结构没问题 (就一个团队)，问题是这个团队被要求承担超出其认知能力的边界——12 个服务的依赖、发布、告警、on-call 全压给 8 个人。解法的方向不是继续拆团队 (会更碎)，而是：合并服务 (把 12 个收敛到 3–5 个)、或引入平台团队承接通用能力、或按服务重要性做取舍。康威定律解释 “边界在哪”，认知负荷决定 “边界能有多大”。