C# 架构精通 — 通过架构扩展团队（康威定律 & .NET）（第11部分）

Source: Dev.to

.NET 中的康威定律

“组织设计的系统会映射其沟通结构。”
— Melvin Conway

这不是建议，而是经验法则。如果你的团队结构混乱，架构也会混乱。

康威定律在代码库中的表现

• 一个巨大的 Web 项目 → 一个巨大的团队
• 到处共享 DbContext → 到处共享所有权
• 上帝服务 → 中心决策瓶颈
• 无尽的合并冲突 → 边界不清

架构揭示了团队的沟通方式。

清洁架构作为补救措施

清洁架构引入：

• 明确的边界
• 清晰的所有权区块
• 稳定的契约

这些能够：

• 并行开发
• 降低协调成本
• 独立决策

边界是社会工具，而不仅仅是技术工具。

垂直切片架构

垂直切片架构自然适配团队规模的扩展。

切片的特征

• 端到端拥有一个功能
• 依赖最小化
• 能够独立演进

这映射的是面向产品的团队，而不是技术孤岛。

共享组件的陷阱

共享组件在早期看似高效，但后来会成为瓶颈。

常见的共享痛点

• 共享 DbContext
• 共享工具库
• 不断膨胀的共享 “core” 项目

共享代码需要共享协调，而这无法扩展。

高绩效组织的团队拓扑

• 流对齐团队 – 拥有功能
• 平台团队 – 为其他团队提供能力
• 赋能团队 – 改进实践

架构应支持这些角色，而不是与之冲突。

好的 vs. 坏的架构问题

明确的所有权比任何工具都更能减少会议。

在不使用微服务的情况下扩展

你不需要微服务来扩展团队。许多 .NET 团队通过以下方式成功：

• 模块化单体
• 清晰的边界
• 垂直切片
• 稳定的契约

微服务解决的是组织问题，而不仅仅是技术问题。

警示信号

• 更改需要大量批准
• 团队回避触碰某些代码
• 恐惧驱动的开发（“只有一个人懂这个”）
• 入职缓慢

这些都是架构症状。

扩展团队前的检查清单

1. 边界是否明确？
2. 所有权是否清晰？
3. 团队能否独立工作？
4. 契约是否稳定？
5. 架构是否映射了期望的沟通模式？

如果答案是否，先扩展架构。

架构的更广泛影响

架构塑造：

• 团队
• 沟通
• 速度
• 文化

你无法超越康威定律的组织限制，但可以在设计时考虑它。

作者：Cristian Sifuentes – 帮助组织通过对齐 .NET 系统的架构、沟通和技术边界来扩展团队。