● 康威定律（Conway’s Law）
原文
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
— Melvin Conway, 1967
翻译
设计系统的组织，其产出的系统架构，必然是该组织沟通结构的复制。
通俗理解
┌─────────────────────────────────────────────────────────┐
│ │
│ 怎么分团队 ──────决定了──────▶ 怎么分系统 │
│ │
│ 人怎么沟通 ──────决定了──────▶ 模块怎么交互 │
│ │
└─────────────────────────────────────────────────────────┘
一句话：公司的组织架构长什么样，系统架构就长什么样。
举例说明
例子1：三个团队
组织架构 系统架构
┌─────────────┐ ┌─────────────┐
│ 前端团队 │ │ 前端应用 │
│ 5人 │ │ │
└──────┬──────┘ └──────┬──────┘
│ │ API调用
│ 开会沟通 │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 后端团队 │ │ 后端服务 │
│ 8人 │ │ │
└──────┬──────┘ └──────┬──────┘
│ │ SQL
│ 发邮件沟通 │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ DBA团队 │ │ 数据库 │
│ 3人 │ │ │
└─────────────┘ └─────────────┘
团队之间有边界 → 系统之间就有接口
例子2：按业务拆团队
组织架构 系统架构
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ 订单组 │ │ 支付组 │ │ 订单服务 │ │ 支付服务 │
│ 5人 │ │ 4人 │ │ │ │ │
└───────────┘ └───────────┘ └─────┬─────┘ └─────┬─────┘
│ │
▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ 用户组 │ │ 商品组 │ │ 用户服务 │ │ 商品服务 │
│ 4人 │ │ 3人 │ │ │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘
4个团队 → 4个服务
例子3：创业公司
组织架构 系统架构
┌─────────────────────────┐ ┌─────────────────────────┐
│ │ │ │
│ 全栈团队 5人 │ │ 单体应用 │
│ 前后端+DBA都在一起 │ │ 一个仓库一个服务 │
│ │ │ │
└─────────────────────────┘ └─────────────────────────┘
没拆团队 → 没必要拆服务
康威定律的推论
推论1：强扭的瓜不甜
❌ 错误做法：
组织架构 系统架构 ┌─────────┐ ┌───┐ ┌───┐ ┌───┐ │ 一个团队 │ → │ A │ │ B │ │ C │ 硬拆微服务 │ 5人 │ └───┘ └───┘ └───┘ └─────────┘ 结果：5个人维护3个服务，扯皮、混乱、低效推论2：系统跟着组织走
✅ 正确做法：
先拆团队，再拆服务 第一步：组织先拆 ┌─────────┐ ┌─────────┐ │ 团队A │ │ 团队B │ └─────────┘ └─────────┘ 第二步：系统跟着拆 ┌─────────┐ ┌─────────┐ │ 服务A │ ←──→ │ 服务B │ └─────────┘ └─────────┘推论3：逆康威定律
如果想改变系统架构，先改变组织架构
想要：微服务架构
必须：先把团队拆成多个独立小组
想要：中台架构
必须：先成立中台团队
现状：
├─ 团队人数：不多
├─ 组织架构：没有拆成几十个小组
├─ 系统架构：几十个微服务
└─ 结论：违背康威定律 ❌
问题：
├─ 人没那么多，服务拆那么细
├─ 沟通成本在团队内部，系统边界却在外部
├─ 一个人跨N个服务开发
└─ 架构和组织不匹配
回归单体：
├─ 组织是一个团队
├─ 系统就该是一个整体
├─ 符合康威定律 ✅
└─ 自然、高效、低成本
总结
| 康威定律核心 | 说明 |
|---|---|
| 组织决定架构 | 不是架构决定组织 |
| 团队边界=服务边界 | 团队怎么分，服务就怎么分 |
| 先拆人，再拆系统 | 顺序不能反 |
| 小团队用单体 | 这是自然规律 |
架构不是技术问题，是组织问题。
