软件的任何一部分都反应了创建它的组织结构
康威定律 (康威法则 , Conway’s Law) 是马尔文·康威1967年提出的：
“设计系统的架构受制于产生这些设计的组织的沟通结构。”——M. Conway[1]
即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
康威定律源于模块的设计者需要互相之间频繁沟通。而跨部门交流比较难。[2]
埃里克·雷蒙在《新黑客词典》中，称康威定律指出了软件架构与软件团队架构的等价（congruent）。例如，“如果你有4个团队在做一个编译器，你会得到一个4遍处理的编译器”。[3][4]
James O. Coplien与Neil B. Harrison在《敏捷软件开发的组织模式》中写道:
“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。”[5]
康威的原文中提出的各定律[1]：
- 第一定律 组织沟通方式会通过系统设计表达出来
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性
- 第四定律 大的系统组织总是比小系统更倾向于分解
Eric Hollnagel在2009年的《Efficiency-Effectiveness Trade Offs》一书中类似的论点：
Problem too complicated? Ignore details. Not enough resources?Give up features.
或者更清楚一点：
组织形式等同其设计的系统架构
许多组织都根据他们的技能来划分团队。因此会有前端开发、后端开发和数据库开发组成的团队。这会导致某人想要修改一个不属于自己领域的东西会很难。
最好是按照有边界的上下文(bounded context)来规划团队，并且越来越多的组织者也正在这么做。像微服务这样的架构围绕服务边界而不是孤立的技术体系划分来组织他们的团队。
康威定律带来的具体的实践建议就是：你想要什么样的系统设计，就架构什么样的团队，这会带来事半功倍的效果。