“设计系统的架构受制于产生这些设计的组织的沟通结构。” ——M. Conway
1. 康威的原文中提出的各定律
- 第一定律 组织沟通方式会通过系统设计表达出来
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性(每个不同的团队可能在做相同的事情)
- 第四定律 大的系统组织总是比小系统更倾向于分解
2. 解读
康威定律阐述了开发团队的组织结构和其设计的产品结构之间具有的相似关系，即系统设计本质上反映了企业的组织机构。
系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
康威定律源于模块的设计者需要互相之间频繁沟通，而跨部门交流比较难。
3. 《新黑客词典》
“如果你有4个团队在做一个编译器，你会得到一个4遍处理的编译器”
4. 《敏捷软件开发的组织模式》
“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。”
5. 《Efficiency-Effectiveness Trade Offs》
效率（获得的劳动效果与所消耗的劳动量的比率）与效力（事物产生的积极作用）的权衡！
Problem too complicated? Ignore details.
Not enough resources?Give up features.
6. 当下
值得一说的是，在一些传统企业内的IT部门划分，往往已经按照职能分为开发团队、运维团队、运营团队，甚至单独的测试团队。在这样的企业中很难快速完成全功能团队的转变，因此在实施微服务架构过程中比较容易走偏。对于这种情况可以采用逐步演进的转换方式，具体途径主要有两种：
第一种方式是进行项目试点。对于习惯了按功能分层、分块的『实现接口开发』式的组织，即使勉强凑齐每个角色的人组在一起也难以成为真正具备端到端交付能力的团队。因此与其做得徒有其表，不如找出项目中一些全局意识比较到位的成员，对特定的项目进行试点，然后逐步扩大，将这种端到端的责任和意识带入到更多的项目中去。试点的项目应该是以实施现有系统的一个独立业务功能点为目标，而不是开发与企业主线系统无关的短期产品，否则容易出现试点项目很成功，但项目结束便不了了之的结果。
第二种方式是先从分开发团队入手，纵向划分项目。这是对全功能团队的一种妥协式的引入方式，即在开发团队中首先改变系统架构横向分层、局部分块的开发模式，依据业务功能进行上至外部接口、下至业务数据的独立服务拆分，但并不急于在开发团队中引入诸如测试、运维、业务等角色的成员。这种项目划分虽然在一定程度上为微服务架构执行制造了条件，但从长远来看，并不能为团队进行自主的技术栈和基础设施选型、以及业务数据的利用提供足够的空间。