康威定律与团队拓扑：组织决定架构

系统架构最终会长成组织沟通结构的复制品——这不是一句口号，而是一条能预测结果的规律：如果结账功能由三个团队共同维护，那么结账代码最终会长成三个互相调用的模块，边界模糊、接口僵硬、每次发布都要三方协调。本章讲两件事：怎么用康威定律（Conway's Law）诊断现有架构，以及怎么用团队拓扑（Team Topologies）反向设计组织，让架构朝期望的方向自然生长。

康威定律的两种读法

读法	视角	用途	典型动作	风险
组织决定架构	描述性 —— 沟通结构映射到系统结构	解释「为什么接口这么别扭」	画组织图与调用图叠在一起找同构关系	只用于归因，不改变任何东西
用架构影响组织	规范性 —— 先定目标架构再调组织	主动让架构长成想要的样子	逆向康威操作（Inverse Conway Maneuver）	只调组织不改协作方式，半年后回到原点

读法一：组织决定架构的可观察信号

1. 最难改的接口，往往正好是两个团队之间的边界
   —— 因为改它需要双倍沟通成本，于是大家选择绕开

2. 调用链的形状 ≈ 团队间的汇报与协作关系
   —— A 服务同步调 B、C、D，常常是因为 A 的团队要等三个团队的结果

3. 组织调整后 3~9 个月，架构会跟着调整
   —— 观察这个滞后窗口，可以验证组织变更是否真的生效

诊断方法很直接：把组织架构图与实际的服务调用图、发布依赖图叠在一起看。如果两张图的形状高度相似，说明康威定律正在起作用；此时想改架构而不动组织边界或协作方式，基本不会成功。

读法二：逆向康威操作

顺序要反过来：先明确目标架构（哪些边界要独立演进），再据此设计团队边界与协作方式，最后让架构自己去收敛。

目标：订单与支付必须能独立发布、独立扩容

逆向康威动作：
  1. 明确边界：订单与支付是两个限界上下文，各自拥有数据
  2. 组建团队：两个流对齐团队，各配一名领域负责人，数据不交叉
  3. 定义交互：先协作（Collaboration）对齐契约，稳定后转为服务（X-as-a-Service）
  4. 治理依赖：禁止跨团队直接改对方数据库，接口变更走版本契约
  5. 观察收敛：3~6 个月后，两个服务的部署流水线与数据库应当再无交叠

团队拓扑四型

团队拓扑（Team Topologies）把团队按职责与交互方式分成四类，核心原则是「团队是交付的单位，也是认知负荷的容器」。

类型	职责	衡量指标	典型反模式
流对齐团队（Stream-aligned）	端到端负责一条业务流：需求、开发、上线、值班	交付周期、变更失败率、SLI 达成	变成「只写代码」的功能团队，把上线交给另一个组
平台团队（Platform）	提供自助式内部平台，让流对齐团队不必自建基础设施	平台采纳率、使用方交付提速、工单量下降	变成「运维审批窗口」或「接单改配置」的服务台
赋能团队（Enabling）	把特定能力（安全、性能、可观测性、测试）教给流对齐团队	能力被内化的团队数、相关缺陷率下降	变成长期驻场外包，或变成又一个审批方
复杂子系统团队（Complicated-subsystem）	专攻高专业度子系统（计算引擎、编解码、实时风控模型）	子系统质量、被复用程度	顺手把业务编排也揽过来，变成隐形的中央团队

关键约束：一个团队同一时间只能是一种类型。一个团队既做平台又做业务流，结果是两项都做不好，且成为所有人的瓶颈。

三种交互模式

交互模式	适用时机	持续时间	退出条件
协作（Collaboration）	探索新边界、新技术，不确定性高	短期、有明确目标	接口稳定后转为服务模式
服务（X-as-a-Service）	边界清晰，一方提供、一方消费	长期	服务不再被需要时下线
促进（Facilitating）	一方把能力传递给另一方	短期、有教学产出	对方能独立完成后撤出

按边界划分团队的实践

顺序是先定边界，再定团队，最后定交互：

1. 划限界上下文：用统一语言找出业务上真正独立的部分（不是按技术分层）
2. 定数据所有权：每个上下文有唯一数据所有者，其他团队只能通过接口访问
3. 定服务数量：每个团队负责的服务数控制在认知负荷之内（见下节）
4. 组队：一个团队 = 一个或几个相关上下文 + 该上下文的代码 + 数据 + 流水线 + 值班
5. 定交互：跨团队接口先协作对齐，稳定后转服务模式，并写明契约与版本策略
6. 处理遗留：拆分过程中出现「暂时共同拥有」的区域，必须登记责任人与退出时间
7. 复核：每个季度看一次发布依赖图，跨团队依赖数应当下降

判断划分是否合理的三个操作性标准：

• 一个团队能否独立发布自己负责的功能？需要三方协调才算完成就说明边界错了。
• 一个团队能否独立值班自己的服务？深夜故障要叫醒别的团队，说明依赖没切干净。
• 一份数据能否有唯一所有者？两个团队都能改同一张表，等于没有边界。

认知负荷与微服务数量

认知负荷（Cognitive Load）分三种，团队能负担多少服务由它决定：

负荷类型	来源	架构可做的改善
内在负荷（Intrinsic）	业务本身的复杂度，无法消除	用统一语言与限界上下文把它表达清楚
外在负荷（Extraneous）	环境带来的额外成本：部署、配置、监控、证书、审批	用平台与自助工具把它降到最低
相关负荷（Germane）	学习与改进的投入，是应该保留的	留出探索时间，别把预算全压在交付上

经验判断：一个团队能长期稳定负担的服务数量通常是 2~5 个，且这个数字随外在负荷变化。这不是技术上限，而是注意力上限——服务的数量等于值班面、发布面、升级面与故障面的数量。

粗算：一个团队每周 100 单位注意力

  业务开发（内在负荷）          40 单位
  部署与发布（外在负荷）        15 单位  ← 有平台可降到 5
  监控、告警、值班（外在负荷）  20 单位  ← 可观测性做得好可降到 10
  学习与改进（相关负荷）        10 单位  ← 最容易被挤掉，最不该挤掉

结论：外在负荷高时团队实际只能维护 1~2 个服务，想加数量先降外在负荷而不是先招人

微服务数量的合理区间由此确定：先算团队能承担的服务数，再决定拆几个服务。倒过来的做法——先按理想架构拆出 30 个服务，再找 5 个团队来养——结局是每个服务都没人真正负责。

信号	说明	该做什么
一个团队要同时处理 8 个服务的告警	超出注意力上限	合并服务，或建平台降低外在负荷
服务很小但值班面很大	拆的是代码不是团队	按团队边界重组服务，而不是按表拆
团队抱怨「一半时间在运维」	外在负荷过高	先建平台团队，再谈拆分
团队能独立发布且几乎不互相等待	边界健康	保持，转服务模式固化

常见误区

误区	后果	正确做法
只调组织不调协作方式与数据所有权	架构不变，两周后回到原状	组织、交互模式、数据边界三者同时调整
平台团队做成审批环节	流对齐团队的交付被卡，平台沦为瓶颈	平台提供自助能力与文档，不做审批
先定服务数量再找团队	服务无人真正拥有，边界名存实亡	先算认知负荷上限，再定拆分粒度
用一个团队兼多种拓扑类型	平台与业务互相挤占，两头都不达标	一个团队同一时期只承担一种类型

边界说明：限界上下文的划分见领域驱动设计章节，模块化单体与微服务的取舍见模块化单体章节，数据所有权与通信选型见服务间通信章节。

小结：康威定律既能用来诊断（调用图与组织图同构，接口别扭处必是团队边界），也能反过来用（先定目标架构，再调团队边界与交互模式，让架构自然收敛）；团队拓扑分流对齐、平台、赋能、复杂子系统四型，一个团队同一时期只承担一种，协作模式必须有退出条件；团队能负担的服务数由认知负荷决定（经验值 2~5 个），想多拆服务要先降低外在负荷——组织决定架构，所以想让架构改变，就得先改变组织与协作。