康威定律对微服务的启示

● 康威定律（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个服务开发
└─ 架构和组织不匹配

回归单体：
├─ 组织是一个团队
├─ 系统就该是一个整体
├─ 符合康威定律 ✅
└─ 自然、高效、低成本

总结

架构不是技术问题，是组织问题。