● 康威定律(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个服务开发
└─ 架构和组织不匹配
回归单体:
├─ 组织是一个团队
├─ 系统就该是一个整体
├─ 符合康威定律 ✅
└─ 自然、高效、低成本
总结
| 康威定律核心 | 说明 |
|---|---|
| 组织决定架构 | 不是架构决定组织 |
| 团队边界=服务边界 | 团队怎么分,服务就怎么分 |
| 先拆人,再拆系统 | 顺序不能反 |
| 小团队用单体 | 这是自然规律 |
架构不是技术问题,是组织问题。