康威定律有一条核心观察，任何设计系统的组织，最终产出的设计结构，都会是该组织沟通结构的翻版。这句话不讨论技术本身，而是点出了一道任何工具都无法绕开的限制。

如果支付团队从不跟风险分析团队沟通，支付服务调用风险API的效率就不会高。应用层面的依赖关系图，会精准复现这种沉默。你可以在画图工具里设计出最优雅的架构，也可以用上服务网格、事件溯源、领域驱动设计，但只要组织内部是一组彼此隔绝的孤岛，软件架构就必然会成为一片独立系统的群岛，群岛之间只架着几座极其脆弱的桥。

打开网易新闻 查看精彩图片

康威定律的特殊之处在于，它不需要任何人去推行，它自己就会实现。两个小组需要协调接口却互不沟通，API的契约就不会经过事先规划，而是在生产环境里临时拼凑出来。三个小组向不同主管汇报，彼此的目标相互冲突，那么软件中就会长出三个限界上下文，它们之间的边界不遵循业务领域的逻辑，只服从公司组织架构图里划出的战壕。

哈佛商学院和麻省理工学院的研究者在2012年发表过一个实证研究，对比了多家企业的软件架构与组织结构。研究发现了一条明确的数学关联：代码的模块化程度，对应着沟通的模块化程度。沟通灵活开放、交叉协作频繁的团队，产出的代码往往拥有更窄的接口和更低的耦合度。沟通的流向塑造了代码的形态。

组织结构与架构之间的传导链路可以逐项审视。两个团队需要集成服务时，必须有人来定义接口契约。如果双方有对话，契约就是商量出来的；如果没有，每一方都会按自己的臆测去实现对方的功能，直到部署那天才发现猜错了。服务代码在仓库里的修改权限如果只属于某一个团队，就会筑起僵硬的边界。于是，权限的归属无声地刻进了软件的分层里。