康威定律和系统设计

最近看到一篇技术分享: 每个架构师都应该研究下康威定律
，对其中提到的康威定律感到好奇， 特此记录分享。

Melvin Conway 在1968年发表的论文《 How Do Committees Invent》中指出:

系统设计的结构必定复制设计该系统的组织的沟通结构。


//维基百科
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

简单来说，系统设计(产品结构)等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构。这时候不得不祭出这张图了：

结合上图和Amazon, Google等公司的产品设计，有没有体会到康威定律的精妙之处？

有意思的是该论点在提出多年内一直默默无名，后来在Brooks Law著名的人月神话中引用这个论点，“康威定律” 从此进入大众的视野。

团队和模块化

有经验的工程师可能注意到一个有趣的现象： 当所有员工在同一地点工作，开发的软件倾向于较少模块化，而若员工分散在不同的地点，开发的软件则倾向于更加模块化、耦合低。

当一支小型团队负责系统的设计与实现时，团队内部可以进行频繁的沟通。而随着团队变大、分布在不同地点甚至时区时，协调沟通成本急剧增加，最终各个地点不得不选择各自专门处理的一部分工作，并在团队之间形成更粗粒度的沟通机制。组织结构中的沟通路径会造就与之对应的粗粒度API，形成代码库各个大块之间的边界。

什么样的团队，产生什么样的架构

想要什么样的系统，你就搭建什么样的团队。如果团队分成前端团队，后台开发团队，DBA团队，系统就会�变成下面的样子：

如果你的系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会变成下面的样子，即微服务的架构。

可见，组织和系统架构之间有一一映射映射关系，两者不对齐就会出各种各样的问题，例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的组织，很难推行微服务和DevOps，这样的组织职能之间都倾向于局部优化，无法形成有效的合作和闭环。

开放问题

1. 我们每个小组内部的组织结构设计是什么样的？�是否和小组所开发的系统架构相类似？
2. 如果公司的系统架构图如下，其团队组织结构该如何构成呢？

参考

• 微服务架构的理论基础 - 康威定理
• 每个架构师都应该研究下康威定律
• 康威定律官方

更多

请关注豆志昂扬微信公众号获取更多内容:

• 直接添加公众号豆志昂扬；
• 微信扫描下图二维码；