什么是康威定律
梅尔 • 康威于 1968 年 4 月在 Datamation 杂志上发表了一篇名为“ How Do Committees Invent”的论文，文中指出：
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.
康威定律主要揭示了交付的架构和组织间的关系.
下面我们先看一下常见的组织结构和交付结果.
组织的松/紧耦合
紧耦合组织, 指的是一起工作的员工在组织管理上的关系紧密，比如商业公司里开发同一个产品特性的组或团队。而松耦合组织, 比如常见的开源项目组织等.
研究发现, 组织的结构对交付的质量确实有深刻的影响。如果组织更加松耦合， 构建的系统更倾向于模块化， 耦合度也越低。
小团队
微软做过一个验证研究，来观察组织结构对交付的软件质量的影响，有兴趣的可以看一下这个结果：The Influence of Organizational Structure On Software Quality: An Empirical Case Study。
而在对技术要求更高的互联网公司，如 Amazon 提出的原则 two pizza team rule，即一个服务的设计、开发、测试和运维人员在一起吃饭，只需两个批萨就够了。Amazon 相信小团队会更加高效，而且对交付的服务更加负责。
Netflix 也是这样，小团队的组织方式很好的保证了他们的独立解耦和快速优化的架构，某种意义上讲，Netflix 为了想要的系统架构，而使用了相应的组织结构。
服务的所有权 和 共享
在不少公司， 存在不少按技术类型划分团队， 即一个服务可被不同团队的人任意修改。
这种情况存在的原因，可能是拆分服务的成本过高，人员不足，或为了避免交付瓶颈。
但这样做有什么弊端呢？ 这会降低团队对交付的关注、责任心和质量。
因此，如今很火的微服务会根据业务领域, 而不是技术进行建模。
如果负责某个微服务的团队与业务领域相匹配, 则它更容易保持对用户和业务的关注, 也更容易进行以特性为导向的开发.
如果真的不能避免服务共享， 可以采用内部开源的方式，进行共享服务。这就有了项目的守护者，不过要注意开源的时机, 需要等到项目比较稳定之后.
当然, 微服务是有成本的, 需要搭建基础设施. 小规模团队并不推荐使用, 因为架构和组织不太匹配, 除非系统和组织规模到一个点, 严重影响效率的时候, 微服务才能更好的发挥威力.
人的问题
康威定律， 其实说的也是管理和人的问题, 毕竟代码是人写的, 组织结构、质量和文化自然会很大程度上影响交付. 在设计系统的时候， 应多考虑组织和系统架构的匹配问题，否则会遇到许多管理、架构和工程等方面的问题。
在<<软件系统架构: 使用视点和视角与利益相关者合作>>这本书中也提到了:
系统架构的目标是解决利益相关者的关注点。
康威定律也正是揭示了这种利益关系对最后交付的影响.
参考
MicroservicePremium
<<微服务设计>> - Sam.Newman
每个架构师都应该研究下康威定律 - InfoQ
软件系统架构：使用视点和视角与利益相关者合作