这是什么
1968年，程序员梅尔文·康威提出了一个看似搞笑实则深刻的定律：'设计系统的组织，其产生的设计等同于组织间的沟通结构。'什么意思呢？如果你的公司有4个团队分别做前端、后端、数据库和运维，那你的系统架构大概率也是这4个模块，而且模块之间的接口'别扭程度'跟团队之间的'沟通难度'成正比。更经典的例子：如果4个团队分别开发编译器，最终产物是一个4-pass编译器。康威定律的启示是：想改变系统架构，你可能需要先改变团队结构。反之亦然——如果你想要某种系统架构，先把团队组织成对应的结构。
什么时候用
设计系统架构时、重组团队时、诊断系统'为什么这么乱'时、微服务/单体架构决策
什么时候别用
极小团队（3-5人）不需要考虑这个定律；系统已经稳定只需小幅修改时
怎么用
- 1
审视你的团队结构
画出当前的团队组织图。哪些人是一个小组？小组之间怎么沟通？
- 2
对比系统架构
画出系统模块图。你会发现它和团队结构惊人地相似
- 3
决定先改哪个
如果想要新的系统架构，先调整团队结构（逆向康威定律）。想要更好的团队协作，先优化系统架构
- 4
用小团队做完整产品
亚马逊的'两个披萨团队'就是对抗康威定律的方法：让每个小团队能独立交付完整功能
真实例子
微服务与团队拆分
Netflix从单体架构迁移到微服务时，不是先把代码拆了，而是先把团队拆成一个个小型自治团队（每个团队负责一个微服务）。他们深刻理解康威定律：系统架构要跟着团队结构走。每个团队像一个小公司，自己开发、自己部署、自己运维。
微软的组织变革
2014年萨提亚·纳德拉接任微软CEO后，打破了原来按产品线（Windows、Office、Server）划分的组织结构，重组为'体验与设备'和'云与AI'两大方向。这个组织变革直接推动了微软从'软件公司'向'云服务公司'的架构转型。