什么是团队拓扑与技术选择
康威定律指出系统结构会趋向组织结构：团队之间怎么沟通，系统边界就会长成什么样。团队拓扑（Team Topologies）进一步给出四种团队类型与三种交互模式，用来降低认知负荷、减少跨团队等待。技术选型不能脱离这层现实：平台能力是否自助、接口由谁负责，直接决定选型能否落地。
基本信息
| 康威定律 | 架构与组织的沟通结构相互映射 |
|---|---|
| 团队类型 | 流对齐团队、平台团队、赋能团队、复杂子系统团队 |
| 交互模式 | 协作、服务、促进三种模式，按需要切换 |
| 判断信号 | 跨团队等待时间、接口归属是否清晰 |
康威定律的应用方式
| 做法 | 说明 | 风险 |
|---|---|---|
| 顺应康威 | 架构边界与团队边界对齐 | 组织变化时架构需同步调整 |
| 逆康威 | 先调整团队再引导架构变化 | 重组成本与过渡期动荡 |
| 平台化 | 通用能力收敛到平台团队 | 平台脱离使用方需求，产出无人使用 |
典型使用场景
- 架构拆分：按团队认知负荷裁剪服务边界，避免一个团队管过多服务
- 平台建设：把日志、CI、发布等横切关注点收敛到平台，业务团队专注领域交付
- 新团队组建：先明确使命与边界，再决定接管或新建哪些服务
- 重组过渡：过渡期保留原有接口与值班安排，避免交付与稳定性断层
- 技术选型：选型前确认团队是否具备运维与排障能力，否则先补平台能力
- 跨团队协作：接口契约用文档与测试显式管理，而不是靠人盯
平台能力与团队职责划分
平台能力与团队职责划分
# 平台团队提供的自助能力（示例）
- 服务脚手架与标准镜像
tracing 与日志采集默认接入
- 发布流水线与灰度通道
- 配置中心与密钥管理
# 业务团队保留的职责
- 领域模型与业务规则
- 服务边界内的容量与性能
- 对外接口语义与兼容性
# 边界原则：平台提供能力而非审批；跨团队接口用契约显式管理逆康威操作要谨慎：重组团队来改变架构，需要同步调整沟通路径、接口归属与值班安排，否则过渡期会同时出现交付与稳定性问题。
按技术分层划分团队会让交付流被反复切割：前端、后端、数据库各一队时，一个需求要穿过多个队列，周期被拉长。