# 01. 架构师的角色

一篇关于 software architect 的长篇模块:架构师与 senior engineer 的区别究竟在哪里、哪些决策必须由架构师亲自掌控,以及责任边界落在何处。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-01-role

---

## 1. 核心观点

Senior engineer 把任务解得很漂亮。架构师则在审视:被放进任务清单的问题,本身是否就是对的问题。

### 架构师为后果负责

> 工程师把门装得笔直。架构师决定的是这扇门到底该开在楼里的哪个位置——好让仓库的物流不会从这里穿堂而过。

senior engineer 和 architect 之间的差别,不在于架构师掌握了更多的 pattern。Senior 通常对一个边界清晰的任务里的解决方案质量负责:实现、简化、提速、写测试、跑 code review。架构师负责的是:解决方案的形态能不能扛住时间的负载——新团队、新客户、数据增长、需求漂移、事故、审计、迁移。

一个好架构师能这样表达:"这个 feature 看起来很小,但它改变了数据 ownership 模型",或者"如果我们现在把这个 contract 暴露出去,以后要维护它好多年"。这不是在拖慢交付。这是在保护团队,免于做出那种"只在当前 sprint 里看起来便宜"的决策。

### 架构师必须亲自掌控什么

> 船长不会去拧船上每一颗螺丝,但他必须掌控航向、海图、风险,以及决定必须改变航线的那一刻。

架构师不需要亲自选每一个库。但他必须掌控那些决定系统轨迹的决策:子系统之间的 boundaries、数据模型、集成 contract、tenancy 策略、安全、observability、reliability、deployment topology、迁移路径。

有一个有用的区分:**reversible decisions** 和 **irreversible decisions**。可逆的决策可以激进地下放——某个具体的 UI 组件、internal helper、服务里日志一行的格式。难以回滚的决策,架构师至少要"看见":数据库的选型、external API、数据 ownership、拆分单体、授权模型。

## 2. 例子与反例

同一个任务可以是工程任务,也可以是架构任务——取决于后果。

### 例子:给博客加评论

> 表面上是个小 feature:一个表单、一个列表、一个提交按钮。但底下很快会冒出权限系统、审核、反垃圾、存储、删除、通知。

工程视角:做一个 `POST /comments` endpoint、一张 `comments` 表、一个列表组件、一个表单。架构视角则会追问:评论是绑在 post 的 slug 上,还是绑在 locale 上?slug 改名了怎么办?谁能删?对用户而言,什么是 source of truth?要不要 soft-delete 模型?如何抵御 spam 和 rate abuse?后面要怎么加 owner moderation?

一个好的架构决策依然可以很简单:一张 comments 表、按 slug 维护 thread、typed domain errors、rate limiting、owner moderation 留到以后。但它已经是一个有意识的决策了。

### 反例:架构师变成总审批人

> 如果所有人都得等一个人来批准重命名某个字段,那就不是架构。那是排队。

差的架构师会把自己变成 bottleneck。他要求评审每一个类,对局部变量的命名争来争去,还称之为"架构管控"。结果是团队不再独立思考,而架构师则淹没在琐碎里。

正确的模型不同:架构师设定原则、边界和 quality gates。团队自己做出局部决策,但知道高风险区域从哪里开始。

#### 自检

- 你的系统里哪些决策回滚成本很高?
- 现在谁拥有这套数据模型?
- 哪些决策团队可以不经架构师就自行决定?
- 架构师在哪些地方从放大器变成了 bottleneck?

下一模块:[Trade-offs](./software-architect-02-tradeoffs)。