Conway's Law（康威定律）由 Melvin Conway 于 1967 年提出，大意是：
设计系统的组织，其产生的设计等价于组织内的沟通结构。
系统模块边界与接口形态，往往会反映团队划分与沟通路径。
典型表现
- 四个互不通气的小组开发编译器，往往得到四遍扫描的编译器。
- 前端 / 后端 / 平台三支队伍若仅在接口评审时协作，系统容易演变成三层大仓加厚适配层。
- 期望微服务「按业务域切分」，却仍按技术栈分团队时，服务边界常漂移回「前端服务 / 某语言服务 / 数据服务」。
定律本身是观察，不是处方。忽略它时，架构图上的理想边界常在组织摩擦下失效。
反向康威（Inverse Conway Maneuver）
现代实践常主动利用该规律：
- 先确定目标架构（服务边界、所有权、交互方式）。
- 再按该边界组织团队（或明确平台 / 赋能团队职责）。
- 使沟通路径与期望的接口路径一致，降低跨团队协调成本。
Team Topologies 中的 stream-aligned、platform、enabling、complicated-subsystem 等形态，本质上是将组织设计作为架构杠杆。
工程对照清单
- 所有权：服务或模块是否有明确负责团队？「人人可改」通常等于无人负责。
- 沟通成本：一次需求变更需跨几个团队协商？成本高处，接口往往变胖或变僵。
- 平台边界：共享平台是自助赋能（清晰 SLA），还是所有功能的必经审批关卡？
- 单体与分布式：组织仍是单一大团队时，强行拆分微服务，常只是把函数调用换成更昂贵的网络调用。
实践含义
架构评审中可增加一项检查：目标架构所对应的沟通结构是否存在。若团队边界与服务边界错位，应优先调整组织或边界之一，而不是仅叠加临时适配层。技术债有时是组织债的利息。