Conway定律和团队拓扑如何塑造微服务？

Question

Accepted Answer

微服务是一个**组织**决策，同样也是一个技术决策。**Conway定律**指出，系统会镜像构建它们的组织的通信结构——因此你的团队结构会塑造你的架构，无论你是否有计划地这样做。

## Conway定律

```text
"Organizations design systems that copy their communication structure."

3 teams that don't talk  →  3 services with awkward, accidental seams
→ Inverse Conway Maneuver: design TEAMS around the architecture you want
```

## 团队所有权

每个服务都应该有一个**明确的所有者团队**来构建、部署和运维它（"你构建它，你就运维它"）。共享所有权会导致服务被忽视。

```text
Orders team   ─owns─▶ Orders service (code + deploy + on-call)
Payments team ─owns─▶ Payments service
→ autonomy: each team ships without waiting on others
```

## 团队拓扑

| 团队类型 | 角色 |
|---|---|
| Stream-aligned | 拥有产品的一个切片（大多数团队） |
| Platform | 提供自助基础设施（CI/CD、mesh） |
| Enabling | 辅导其他团队进行实践 |
| Complicated-subsystem | 拥有一个深度专业领域 |

目标是最小化跨团队的**认知负荷**和交接。

## 陷阱

在不重组团队的情况下采用微服务会产生分布式单体，因为旧的协调模式会泄漏到架构中。

## 为什么这很重要

如果团队必须不断协调以交付一个功能，无论你如何清晰地绘制服务图，架构都会反映这种耦合。

将团队边界与服务边界对齐（逆向Conway手法）才是真正实现微服务承诺的自治和独立部署优势的方法——组织结构图是设计的一部分。