什么是康威定律？
Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967) 设计系统的架构受制于产生这些设计的组织的沟通结构。
组织设计背后的生产关系逻辑
动物界有个非常有趣的现象，群居性动物，为了保证群体的稳定性，都有两个比较有意思的特征就是等级和分工，而等级和分工最终会演化成类似金字塔形式的结构，这种结构就是组织结构。
如在蚂蚁世界，会有如下分工，职能和边界清晰
- 蚁后(具有受精和生殖能力的雌性蚂蚁,承载着繁衍工作)
- 雄蚁 雄蚁是蚁群中唯一的雄性蚂蚁。完成交配后不久即死亡。
- 工蚁 是不发育的雌性,一般为群体中最小的个体,但数量最多
再如大到人类历朝历代的中枢机构，秦朝的三公九卿制、隋朝的三省六部制、宋朝的二府三司制、元朝的行省制度，元朝的中书省制，甚至现在的人们代表大会制度，小到家庭成员的构成，无不体现着群体性动物的特征：等级和分工。
组织架构的设计，本质上有了两个层面的含义:
- 是生产力和生产关系的体现。按照这种设计会产生最大化的效益产出。当一个企业的生产力跟不上生产关系时，组织上会做出相应的调整，比如某一个业务部门因为整体业务不好(生产力不足)，企业经营者会砍掉这个业务部门。
- 是代表的时企业的运作方式和沟通关系。一个组织架构的设计分为节点和线组成，节点表示的生产力，而连线，表示的生产关系，而生产关系又可以做一些细分，从重要程度上，可以简单的概括为：汇报关系、业务合作关系、协同关系。在运作的过程中，实际反映的是人与人的沟通关系。
上面的论述可能有点抽象，可以看下现实的例子：以典型的几个互联网公司的组织架构上来看，透过组织结构，就可以了解到一个公司的沟通方式，甚至基于组织架构的设计，还能透出其企业的崇尚某种文化。
从逻辑上，会有如下的关系：
组织结构决定软件系统结构
组织结构确立了，相当于生产关系确立，对应的沟通方式也就确定了。
如下图所示，是一个一般的简单大的公司运作模式：采购部门像供货商采购商品，然后将采购的商品给销售部门进行销售；而账务部门需要将采购部门的采购单和销售部门的销售单进行对账。
假设你是这个公司的CIO负责这个公司的信息化，来满足各个部门的日常工作，那么会很自然地设计出如下几个系统：
综上所述, 软件系统实际上只是通过信息化的方式，来完成企业的组织结构内的成员的既有的沟通协作模式。
这种本质，就是马尔文·康威在1967年提出的《康威定律》：
Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967) 设计系统的架构受制于产生这些设计的组织的沟通结构。
康威定律的解读
基于康威定律的定义，可以从下面四个层面来看：
第一定律
Communication dictates design。 组织沟通方式决定系统设计。
经验一：为什么组织设计要追求小团队？
根据上一章节的例子可以看出，现实中组织结构中的沟通方式是怎样的，通过信息化的方式实现的系统就是怎样的。 如果组织结构中的沟通过程很复杂，沟通的成本很高，那么，相应的系统间的交互也就变得异常复杂; 而对于软件系统而言，当复杂度超过一定范围时，就会变得不可维护，导致系统瓶颈无法支持业务。
《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = n(n-1)/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
所以在组织设计上，应当追求小团队，一是沟通成本低，二是背后的软件系统的复杂度低。这也是为什么互联网公司都追求小团队的原因之一。沟通的问题会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。
经验二：微服务架构模块划分要充分考虑团队人员结构
微服务架构的拆分实践上一个很大的误区，就是纯粹根据领域依赖关系直接拆分 而忽略的团队的人员构成。
举一个例子：假设一个研发团队要做一个营销平台系统，架构师觉得微服务比较流行，然后尝试进行微服务拆分，所以根据领域关系，拆分了六个微服务模块，然而研发团队只有3名成员，按照这样的设计，每个成员要维护 2 个微服务，如果要做一个简单的功能，一个成员需要到两个微服务上开发，让微服务开放出 RPC接口，然后在BFF中做能力整合。这种开发行为本身就是不正确的。 另外，微服务的拆分，还会导致分布式事务等其他的问题，在本来研发资源就不充足的情况下，增加了大量的额外成本，最终影响交付质量。 如果业务发展比较好，公司有足够的资金来壮大团队，比如按照微服务设计每个微服务模块投入 10名研发人员(共 10 * 6 = 60) 的研发规模，那这个架构设计我认为至少是合理的；但是如果公司投入有限，总共只能投入非常有限(如10人内)的资源，我的建议是尽可能不要使用微服务架构，或者减少微服务的模块数量。
所以：微服务的拆分，要确保有足够的研发组织保障为前提，结合领域依赖和业务特性为原则。
第二定律
There is never enough time to do something right, but there is always enough time to do it over。 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
软件系统的形成，分为两阶段：首先人类对现实世界的某个领域的运作方式的理解和认知，第二个阶段是基于理解和认知由开发人员进一步抽象然后实现。而无论哪个阶段，都不可能做不到完美。 事物本身在不断发生改变，人类也会在不同的阶段有不同的认知，所以: 不要想着花大量的时间设想着可以设计一套自认为可以完美支持某个领域内所有场景的系统。而是着眼于眼前的业务域问题，解决好，支持好。
没有完美的系统，只有不断完善和演化的系统。
- 人手永远是不够的，事情永远是做不完的，但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况，敏捷开发可以做到不断迭代、持续交付、快速验证和反馈，并持续改进。
- 再牛的开发也会写出bug，再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题，是容忍一些问题的存在，然后通过适当的设计（冗余、监控、高可用设计）当问题发生时能够快速解决。 好的架构不是买来的，也不是设计出来的，而是根据业务落地生根长期演化来的。
第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization。 线型系统和线型组织架构间有潜在的异质同态特性。
首先解释下 “异质同态”: 虽然不是同一个事物，但是他们的形态(如之间的逻辑关系，构成)保持一致。
这个特性其实和康威定律的定义项对应。如上面举例，业务部门的构成，决定了对应的业务系统，而业务部门之间的沟通方式，决定了业务系统之间的接口设计。
在软件系统设计的时候，要充分考虑组织和系统之间的异质同态性。
第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。 大的系统组织总是比小系统更倾向于分解。
组织的沟通成本，随着成员数量的增加而指数级增加。为了降低复杂度，会出现各种组织趋于分解的设计，如金字塔的分层模型，以控制每一个节点的关联的数量。而对应地，软件系统也会根据这一趋势，甚至是软件系统会随着组织结构的复杂度过高，而导致系统无法继续维护。 所以，无论是从组织设计上，还是软件架构设计上，都是大系统比小系统更趋于分解。
分解是应对复杂度的基本解决之道。
