Software Architect · 模块 01
架构师不是那个画漂亮图的人。架构师是为系统形态以及决策在时间维度上的后果负责的工程师。
角色 · ownership · 时间视野
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、拆分单体、授权模型。
同一个任务可以是工程任务,也可以是架构任务——取决于后果。
例子:给博客加评论
表面上是个小 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?