---
title: "康威定律：你公司的组织架构，就是你的系统架构"
description: "1967 年程序员 Melvin Conway 观察到的一个现象——系统的技术结构会忠实地复制设计它的组织的沟通结构。半个世纪后，它成了软件架构领域最硬的常识之一。"
date: "2026-08-12"
type: "notes"
kind: "note"
tags:
  - 软件工程
  - 组织管理
  - 架构
draft: false
---

**康威定律**（Conway's Law）说的是，设计系统的组织，其沟通结构会决定这个系统的架构。用更直白的话讲，你把一群人怎么分成部门、怎么沟通，最后做出来的系统就会长成什么样。

这个说法来自程序员 Melvin Conway，1967 年写在一篇投稿里。Conway 是协程（coroutine）概念的提出者，在计算机语言和系统编程领域都有早期贡献，康威定律是他留给行业影响最大的观察。他当时想表达的意思很简单，系统的各个模块之间需要人去协调接口，而人跨部门沟通的成本天然比部门内部高。所以系统的边界，会不知不觉地跟组织的边界对齐。

这篇投稿被杂志退了，编辑的理由是"这太显而易见了，不算新发现"。但两年后的 1968 年，美国国家模块化编程研讨会上，参会者讨论了一圈以后一致认为这个观察足够普遍，值得给它起个名字，于是就有了"Conway's Law"。

## 什么叫"系统长得像组织"

Eric Raymond 在《新黑客词典》里给过一个经典例子，"如果你有四个团队在做一个编译器，你会得到一个四遍处理的编译器。"

这话说起来像段子，实际发生得非常自然。每个团队负责编译器的一个阶段，团队内部沟通成本低，可以快速迭代。但团队之间要协调接口，成本就上去了。于是每个团队干脆把自己那部分做得尽量自洽，跟其他团队的交互压缩到最简。最终的结果就是四个阶段、四次遍历，架构跟团队划分一模一样。

Nigel Bevan 在 1997 年的一篇论文里写过类似的观察。很多公司做的网站，内容结构反映的是公司内部的部门划分，用户想看的内容反而被拆散了。产品部负责产品页面，市场部负责品牌页面，技术部负责 API 文档。用户关心的问题，比如"这个产品跟竞品比怎么样"，可能跨越三个部门，谁都没有完整地回答。

## 镜像假说把问题带进了实证研究

康威定律听起来像经验之谈，后来有研究把组织结构和产品结构放在一起比较。

MIT 的 Alan MacCormack 和哈佛商学院的 Carliss Baldwin 合作过一个研究项目，叫做"镜像假说"（Mirroring Hypothesis），核心问题是组织架构和产品架构之间到底存不存在系统性的对应关系。

这类研究通常把组织结构和产品模块之间的对应关系称为镜像关系。它们支持一个较窄的判断，组织之间的依赖关系会影响产品模块之间的依赖关系。这个结论不等于组织一变，产品就会自动得到理想的架构。

马里兰大学和微软合作的另一个研究，Tampere 理工大学的独立案例，结论也都指向同一个方向。

## 因果关系到底谁决定谁

康威本人说的只是"对应"，没说谁决定谁。后来的人在这个问题上分了好几派。

一派认为组织结构决定系统架构。你是怎么分团队的，系统就怎么分模块，组织是因，架构是果。

另一派反过来，认为好的技术架构会反过来迫使组织调整。微服务就是一个例子，很多公司拆了微服务以后发现，原来按数据库表分的前端团队跟不上节奏，只好把团队也拆成一个个小队，每个小队负责一个服务。

还有一种看法认为两者互为因果，组织改了架构跟着变，架构定了组织也得跟上，最终会趋向一种稳定态。

三种说法各有道理。实际工作中，你很少有机会做严格对照实验，所以很难说清谁是因谁是果。但有一点是确定的，长期来看，组织和架构不匹配的系统，两边的摩擦会逼着至少一方做出改变。

## Yourdon 和 Constantine 的加强版

Edward Yourdon 和 Larry Constantine 在 1979 年的书《结构化设计》里，把康威定律往前推了一步，直接用了"同构"这个词，

> 任何系统设计出来的结构，都和设计它的组织的结构同构。

这比 Conway 自己的表述要强硬得多。Conway 只说"对应"，Yourdon 和 Constantine 直接说"同构"，等于在断言结构和组织之间存在数学意义上的等价关系。

Coplien 和 Harrison 在 2004 年的《敏捷软件开发的组织模式》里则从实践角度给出了反向建议，

> 如果组织的各个部分没有紧密反映产品的核心组成，或者组织之间的关系没有反映产品部分之间的关系，这个项目就会遇到麻烦。所以，要确保组织结构与产品架构兼容。

这等于在说，如果你承认康威定律是对的，那你就应该主动利用它。先想清楚产品应该长什么样，再把团队组织成对应的形状，让定律替你工作。

## 康威本人提过不止一条

中文维基百科收录了康威原文中的四条定律，除了最常被引用的第一条，还有三条。

第二条，时间再多一件事情也不可能做得完美，但总有时间做完一件事情。

第三条，线型系统和线型组织架构之间有潜在的异质同态特性。

第四条，大的系统组织总是比小系统更倾向于分解。

第二条可以看作项目管理中的提醒。第三条讨论层级结构和管道结构之间的对应，编译器的多遍处理是常见例子。第四条讨论规模效应，系统变大以后，组织和架构都更容易出现拆分。

这四条放在一起看，康威的观察比"架构像组织"要宽得多。他实际上在描述组织、沟通、规模和系统产出之间的一组系统性关系。

## 康威定律今天怎么用

在软件行业，康威定律已经从"有趣的观察"变成了一种实践工具。

做微服务拆分的时候，很多人会先画团队边界，再看系统怎么拆。Confluent 的联合创始人 Jay Kreps 写过关于团队边界和系统设计的文章，讨论了团队之间的依赖怎样影响服务边界。更实际的做法，是让负责一块产品能力的团队拥有清晰的责任和沟通路径。

反过来也一样。如果你发现系统的某些模块之间的耦合总是解不开，也许问题不在技术，在于这两个模块背后的两个团队之间没有建立起足够的沟通机制，或者干脆就是两个不该分开的团队被硬分开了。

康威定律的作用在于，它把一个看起来纯技术的问题带回到人和组织。下次你觉得系统架构"不太对"，但又说不清哪里不对时，可以先看看团队是怎样分工和沟通的。

## 关联词

- **微服务**，一种把系统拆成独立服务的架构风格，跟康威定律的关系最密切，拆服务经常意味着拆团队。
- **Inversion of Conway's Law**，反向操作，先设计理想的系统架构，再调整组织来匹配。Netflix 和 Spotify 都公开用过这个思路。
- **The Mythical Man-Month**，Fred Brooks 的经典著作，1975 年出版，同样在讨论大型技术组织的系统性问题。
- **团队拓扑**，Matthew Skelton 和 Manuel Pais 提出的组织设计方法，可以看作康威定律在实践层面的延伸。

## 参考资料

- [Wikipedia: Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law)
- [维基百科: 康威定律](https://zh.wikipedia.org/wiki/康威定律)
- Alan MacCormack, John Rusnak & Carliss Baldwin, "Exploring the Duality between Product and Organizational Architectures," Research Policy, 2012
- Edward Yourdon & Larry Constantine, *Structured Design*, 1979
- James O. Coplien & Neil B. Harrison, *Organizational Patterns of Agile Software Development*, 2004