最近看到一篇技术分享: 每个架构师都应该研究下康威定律
，对其中提到的康威定律感到好奇， 特此记录分享。
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，这样的组织职能之间都倾向于局部优化，无法形成有效的合作和闭环。
开放问题
- 我们每个小组内部的组织结构设计是什么样的？�是否和小组所开发的系统架构相类似？
- 如果公司的系统架构图如下，其团队组织结构该如何构成呢？
参考
更多
请关注豆志昂扬微信公众号获取更多内容:
- 直接添加公众号豆志昂扬；
- 微信扫描下图二维码；
网友评论