名称: 逆康威操作 描述: 使用逆康威操作对齐架构和团队结构 允许工具: 读取、全局搜索、过滤、写入、编辑
逆康威操作技能
何时使用此技能
使用此技能当：
- 逆康威任务 - 处理使用逆康威操作对齐架构和团队结构的任务
- 规划或设计 - 需要逆康威方法的指导
- 最佳实践 - 希望遵循既定模式和标准
概述
应用逆康威操作来刻意设计团队结构以实现期望的架构。
强制要求：文档优先方法
在应用逆康威操作前：
- 调用
docs-management技能 用于架构团队对齐 - 通过 MCP 服务器验证康威模式（perplexity）
- 基于团队拓扑和领域驱动设计文献提供指导
康威定律
康威定律：
"设计系统的组织，其产生的设计等同于组织间的沟通结构。"
— Melvin Conway, 1968
含义：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 团队 A │ │ 团队 B │ │ 团队 C │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 组件 A │◄──►│ 组件 B │◄──►│ 组件 C │
└─────────────┘ └─────────────┘ └─────────────┘
如果团队沟通，它们的组件将集成。
如果团队不沟通，它们的组件不会良好集成。
逆康威操作
逆康威操作：
替代：团队结构 → 架构（自发性）
这样做：期望架构 → 团队结构（刻意性）
过程：
1. 设计目标架构
2. 识别所需的沟通模式
3. 重构团队以匹配
4. 架构跟随团队
┌─────────────────────────────────────────────────────────┐
│ 目标架构 │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 服务 A │ │ 服务 B │ │ 服务 C │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ 平台 │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────────────┘
│
▼ 设计团队以匹配
┌─────────────────────────────────────────────────────────┐
│ 团队结构 │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 团队 A │ │ 团队 B │ │ 团队 C │ │
│ │（服务 A） │ │（服务 B） │ │（服务 C） │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └───────────────┼───────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ 平台 │ │
│ │ 团队 │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────────────┘
架构团队对齐
有界上下文到团队映射
领域驱动设计有界上下文 → 团队映射：
有界上下文 团队
┌─────────────────┐ ┌─────────────────┐
│ 订单上下文 │ ───────► │ 订单团队 │
│ │ │ │
│ • 订单 │ │ • 全栈 │
│ • 订单项 │ │ • 自有部署 │
│ • 订单状态 │ │ • 自有数据 │
└─────────────────┘ └─────────────────┘
┌─────────────────┐ ┌─────────────────┐
│ 支付上下文 │ ───────► │ 支付团队 │
│ │ │ │
│ • 支付 │ │ • 全栈 │
│ • 交易 │ │ • 自有部署 │
│ • 退款 │ │ • 自有数据 │
└─────────────────┘ └─────────────────┘
好处：
✓ 清晰的归属感
✓ 减少协调
✓ 自主部署
✓ 领域专长
集成接口
上下文交汇处 → 团队接口：
┌─────────────────┐ API 契约 ┌─────────────────┐
│ 订单上下文 │◄───────────────────►│ 支付上下文 │
│ │ │ │
│ 团队 A │ 清晰接口 │ 团队 B │
└─────────────────┘ └─────────────────┘
集成模式：
• 共享内核：小型共享代码（谨慎使用）
• 客户-供应商：一方为另一方服务
• 防腐层：在上下文之间转换
• 开放主机服务：为多消费者发布的API
应用逆康威操作
步骤 1：定义目标架构
架构愿景：
1. 识别关键组件/服务
2. 定义边界（有界上下文）
3. 指定集成模式
4. 注意扩展需求
5. 考虑运营方面
问题：
□ 将存在哪些服务？
□ 边界是什么？
□ 服务如何通信？
□ 每个拥有什么数据？
□ 部署单元是什么？
步骤 2：映射沟通需求
沟通矩阵：
│ 服务 A │ 服务 B │ 服务 C │ 平台
───────────┼───────┼───────┼───────┼──────────
服务 A │ - │ 低 │ 无 │ 高
服务 B │ 低 │ - │ 高 │ 高
服务 C │ 无 │ 高 │ - │ 高
平台 │ 高 │ 高 │ 高 │ -
高 = 频繁、详细协调
低 = 偶尔、定义良好的接口
无 = 不需要直接沟通
步骤 3：设计团队结构
团队结构规则：
1. 每个有界上下文一个团队
- 完全所有权
- 减少依赖
- 清晰责任
2. 最小化团队依赖
- 如果 A 和 B 需要大量协调 → 同一团队
- 如果 A 和 B 独立 → 分开团队
- 如果依赖是 API 仅 → 分开团队 OK
3. 适当规模
- 每个团队 5-9 人
- 能理解整个领域
- 可控的认知负荷
4. 平台团队满足共享需求
- 公共基础设施
- 共享服务
- 自助服务焦点
步骤 4：规划过渡
过渡方法：
逐步演化：
第 1-4 周：在一个边界试点新团队结构
第 5-8 周：扩展到相邻边界
第 9 周及以上：全面推行
大爆炸（风险高）：
第 1 天：新结构就位
要求：清晰沟通、快速稳定
混合：
• 宣布新目标结构
• 允许有机移动
• 时间限制过渡
常见模式
单体到微服务
从：
┌─────────────────────────────────┐
│ 单体团队 │
│ （每个人都负责所有内容） │
└─────────────────────────────────┘
到：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 订单 │ │ 支付 │ │ 发货 │
│ 团队 │ │ 团队 │ │ 团队 │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└─────────────┼───────────────┘
│
┌───────┴───────┐
│ 平台 │
│ 团队 │
└───────────────┘
方法：
1. 在单体中识别有界上下文
2. 将团队分配到上下文
3. 逐步提取服务
4. 随团队移动代码所有权
功能团队到流对齐团队
从：
┌──────────────────────────────────────────────┐
│ 功能团队 │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │功能 │ │功能 │ │功能 │ │
│ │团队 1 │ │团队 2 │ │团队 3 │ │
│ └────────┘ └────────┘ └────────┘ │
│ （在任何代码库部分工作） │
└──────────────────────────────────────────────┘
到：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 流 │ │ 流 │ │ 流 │
│ 对齐 1 │ │ 对齐 2 │ │ 对齐 3 │
│ │ │ │ │ │
│ 拥有：搜索 │ │ 拥有：购物车 │ │拥有：结账 │
└─────────────┘ └─────────────┘ └─────────────┘
方法：
1. 识别价值流
2. 按流映射当前贡献
3. 将团队分配到流
4. 逐步转移所有权
反模式
逆康威操作反模式：
1. 忽略当前状态
- 不要试图一夜之间改变一切
- 承认现有结构
- 规划逐步过渡
2. 将架构强加于不情愿的团队
- 需要支持，而不是强制
- 解释为什么
- 支持过渡
3. 创建不现实的边界
- 边界应该是自然的
- 团队太多 → 太多协调
- 团队太少 → 认知过载
4. 忽视平台需求
- 流对齐团队需要平台支持
- 平台团队减少重复
- 自助服务是目标
5. 忽视人员
- 技能需要匹配团队
- 职业路径重要
- 文化适应重要
评估模板
# 逆康威分析：[组织]
## 当前状态
### 当前架构
```text
[当前架构图表]
当前团队
| 团队 | 职责 | 规模 |
|---|---|---|
| [名称] | [他们拥有的内容] | [N] |
不对齐
| 问题 | 影响 |
|---|---|
| [不对齐] | [效果] |
目标状态
目标架构
[目标架构图表]
目标团队
| 团队 | 类型 | 职责 |
|---|---|---|
| [名称] | [类型] | [他们将拥有的内容] |
沟通分析
必要交互
| 从 | 到 | 频率 | 类型 |
|---|---|---|---|
| [团队] | [团队] | [高/中/低] | [API/协作] |
过渡计划
阶段 1：[时间范围]
- [行动]
- [行动]
阶段 2：[时间范围]
- [行动]
- [行动]
风险
| 风险 | 缓解策略 |
|---|---|
| [风险] | [策略] |
工作流
应用逆康威操作时：
- 文档当前状态：今天的架构和团队
- 设计目标架构：我们想要什么结构？
- 映射边界：识别有界上下文
- 设计团队结构：团队匹配架构
- 识别过渡：如何从当前到目标
- 规划执行：分阶段方法
- 执行和适应：基于反馈迭代
参考
详细指导：
最后更新： 2025-12-26