Mel Conway 康威在加利福尼亞理工學院獲得物理學碩士學位，在凱斯西儲大學獲得數學博士學位。畢業之后，他參與了很多知名的軟件項目，如 Pascal 編輯器。在他的職業生涯中，康威觀察到一個現象：軟件團隊開發的產品是對公司組織架構的反映。
1967 年他針對這個現象提交了一篇論文。（http://www.melconway.com/Home/Conways_Law.html）給 《哈佛商業評論》。結果程序員屌絲的文章不入商業人士的法眼，無情被拒，康威就投到了一個編程相關的雜志，所以被誤解為是針對軟件開發的。
最初這篇文章顯然不敢自稱定律（law），只是描述了作者自己的發現和總結。后來，在Brooks Law著名的人月神話中，引用這個論點，並將其“吹捧”成了現在我們熟知“康威定律”。
康威定律的核心如下：
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
任何設計系統的組織，必然會產生以下設計結果：即其結構就是該組織溝通結構的寫照。簡單來說： 產品必然是其組織溝通結構的縮影。
為什么溝通會影響產品、架構等？
在《人月神話》 中提到這樣一個觀點：
Adding manpower to a late software project makes it later --Fred Brooks, (1975)
為了趕進度加程序員就像用水去滅油鍋里的火一樣（無奈大家還是前赴后繼）。
為什么會有這樣的情況，《人月神話》中給出了簡潔的答案：
溝通成本 = n(n-1)/2，溝通成本隨着項目或者組織的人員增加呈指數級增長。是的，項目管理這個算法的復雜度是O(n^2)。舉個例子：
- 5個人的項目組，需要溝通的渠道是 5*(5–1)/2 = 10
- 15個人的項目組，需要溝通的渠道是15*(15–1)/2 = 105
- 50個人的項目組，需要溝通的渠道是50*(50–1)/2 = 1,225
- 150個人的項目組，需要溝通的渠道是150*(150–1)/2 = 11,175
所以知道為什么互聯網創業公司都這么小了吧，必須小啊，不然等CEO和所有人講一遍創業的想法后，風投的錢都燒完了。
Mike Amundsen 在 《遠距離條件下的康威定律——分布式世界中實現團隊構建》 講座中（http://www.infoq.com/cn/presentations/team-building-implementation-in-distributed-world ）還舉了一個非常有意思的理論，叫“Dunbar Number”，這是一個叫Dunbar（廢話）生物學家在1992年最早提出來的。最初，他發現靈長類的大腦容量和其對應的族群大小有一定關聯，進而推斷出人類的大腦能維系的關系的一些有趣估計。舉例來說
- 親密（intimate）朋友: 5
- 信任（trusted）朋友: 15
- 酒肉（close）朋友: 35
- 照面（casual）朋友: 150
溝通的問題，會帶來系統設計的問題，進而影響整個系統的開發效率和最終產品結果。
什么樣的團隊，產生什么樣的架構
你想要什么樣的系統，就搭建什么樣的團隊。如果你的團隊分成前端團隊，Java后台開發團隊，DBA團隊，運維團隊，你的系統就會長成下面的樣子：
典型的分層架構：
如果你的系統是按照業務邊界划分的，大家按照一個業務目標去把自己的模塊做出小系統，小產品的話，你的大系統就會長成下面的樣子，即微服務的架構。
微服務的理念團隊間應該是 inter-operate, not integrate 。inter-operate是定義好系統的邊界和接口，在一個團隊內全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，將溝通的成本維持在系統內部，每個子系統就會更加內聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。
參考資料：
微服務架構的理論基礎 - 康威定律
https://yq.aliyun.com/articles/8611
每個架構師都應該研究下康威定律
http://www.infoq.com/cn/articles/every-architect-should-study-conway-law