Conway's Law

解决什么问题：承认组织结构决定系统架构，反向利用它——先设计团队，再设计系统——避免"想做出好架构，但被组织结构拖后腿"，转而把 Conway 定律作为架构设计的工具。

它是什么

康威定律（Conway's Law） 是 Melvin Conway 在 1968 年提出的观察：

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." 设计系统的组织，其产生的设计必然是组织沟通结构的副本。

换句话说：系统架构 = 组织结构的镜像——团队的沟通渠道决定了系统的接口边界。

控制论 Ch 21 §21.3 分散控制的设计给出了数学依据： "分散控制的设计本身 = 系统结构的设计——子系统的边界必须对应局部控制器的边界。" 软件工程对位：子系统的边界（服务 / BC）= 团队的边界。

SE@G Ch 3 "Programming over Time" 印证： "The structure of your codebase reflects the structure of your organization."——代码库结构 = 组织结构。

IDDD Ch 3 Bounded Context 与团队的对应： Vernon 反复强调：每个 BC 必须有一个明确的团队 owner——没有团队 owner 的 BC = 没有维护者的孤儿代码。

V2 视角（V2.7 B7 段 5）：Conway 定律是 B7 演化的组织前提——业务要演化，组织要先演化（团队重组）；组织不演化 = 系统不能演化。

关键属性

属性	含义	软件工程对位
镜像关系	系统结构 = 组织结构	服务边界 = 团队边界
沟通渠道	团队间沟通渠道 = 系统接口	API / 事件 / 共享代码
约束性	不是建议，是约束	试图跨团队改服务 = 跨组织协调
可利用性	反向利用：先设计团队	"Inverse Conway Maneuver"
可演化性	团队演化 → 系统演化	重组团队 = 推动架构演化
跨边界代价	跨团队协作成本高	跨 BC 修改需要协调
团队规模	影响沟通渠道数量	5-9 人团队 / 3 个披萨原则
文化影响	组织文化 → 系统文化	"零故障" 文化 → 隐藏故障

怎么用

场景 1：识别 Conway 定律的影响

典型症状：

1. 两个服务高度耦合，但分属不同团队
   → Conway 失配：架构和团队边界不一致

2. 一个服务被多个团队共同维护
   → 没人有 end-to-end 所有权 = 系统级失稳

3. 一个团队的代码被多个服务依赖
   → 关键路径跨团队 = 任何变更都需要协调

4. 服务边界和业务边界不一致
   → 服务随业务变化时，跨服务修改成本高

场景 2：Inverse Conway Maneuver（反向 Conway）

原则：先设计团队结构，再设计系统结构——而不是反过来。

步骤：
1. 明确业务目标（B7 演化的目标）
2. 设计团队结构（谁负责什么业务能力）
3. 团队结构 → 服务边界（每个团队 = 一个 BC owner）
4. 服务接口 = 团队沟通契约（API / 事件）

例：
- 业务目标：支持多品类生鲜
- 团队结构：订单 / 库存 / 支付 / 履约 4 个团队
- 服务边界：4 个 BC 对应 4 个团队
- 接口：事件驱动 + API 网关

关键：团队重组比服务重组成本低——先重组团队，再用团队结构驱动服务重组。

场景 3：Conway 定律的健康检查

5 个检查项：

1. 每个 BC 有明确的团队 owner？
   → 否 = Conway 失配

2. 团队的沟通渠道数 = 服务的依赖数 ± 1？
   → 否 = 团队 / 服务耦合失配

3. 团队规模是否在 5-9 人之间？
   → 否 = 沟通成本失控（太大）或能力不够（太小）

4. 跨团队修改的频率？
   → 频繁 = 边界设计有问题

5. 团队目标和业务目标对齐？
   → 否 = 局部优化 = 全局失败

场景 4：Conway 定律的工程实践

实践 1：每个 BC 一个团队（Team-as-a-Service）

规则：
- 每个 BC 有明确的 team owner
- team owner 负责该 BC 的演化、SLO、迭代
- 跨 BC 修改需要协调，但不强制

实践 2：3 个披萨原则（Two-Pizza Team）

规则：
- 团队规模 ≤ 6-8 人（两个披萨能喂饱）
- 超过 = 拆分团队
- 小于 3 人 = 团队能力不够

依据：沟通渠道数 = n(n-1)/2，团队越大沟通成本指数增长

实践 3：跨团队契约（API / 事件）

规则：
- 跨团队沟通 = 明确的 API 契约或事件 schema
- 不要通过共享代码或共享数据库耦合
- 契约变更需要 deprecation 流程

实践 4：平台团队（Platform Team）

规则：
- 平台团队提供基础设施（CI/CD、监控、日志、消息总线）
- 业务团队基于平台自服务
- 平台团队不参与业务决策

依据：Team Topologies 的 Stream-Aligned / Platform 模式

常见误区

"Conway 定律是观察，不是工具" ——错。Conway 定律既是约束也是工具——Inverse Conway Maneuver 正是反向利用
"团队结构跟着系统结构变" ——错。先变团队，再变系统——团队重组成本比系统重组低
"Conway 定律只影响架构" ——错。Conway 定律影响架构 + 沟通 + 文化 + 决策速度
"小团队 = 好" ——错。3 人以下团队能力不够；9 人以上团队沟通失控。5-9 人最优
"Conway 定律 = 跨团队协作不可行" ——错。跨团队协作可行，但成本高——通过明确的 API / 事件契约降低

关键洞察

Conway 定律 = 系统结构 = 组织结构的镜像。不是观察，是工程工具——通过 Inverse Conway Maneuver 反向利用：先设计团队，再设计系统。 控制论 Ch 21 分散控制的设计 = 系统结构的设计 + SE@G Ch 3 代码库结构 = 组织结构 + IDDD Ch 3 BC 必须有团队 owner——三源汇成同一结论。 B7 演化的组织前提：业务要演化，组织要先演化；团队重组是架构演化的第一步。 关键纪律：每个 BC 有明确团队 owner + 5-9 人团队 + 跨团队契约明确 + 平台团队支持基础设施。

Conway's Law ​

它是什么 ​

关键属性 ​

怎么用 ​

场景 1：识别 Conway 定律的影响 ​

场景 2：Inverse Conway Maneuver（反向 Conway） ​

场景 3：Conway 定律的健康检查 ​

场景 4：Conway 定律的工程实践 ​

常见误区 ​

关键洞察 ​

相关链接 ​