笔记
读书笔记｜《Fundamentals of Software Architecture》
六步架构设计方法论：从商业理解到组织成长形成闭环，在权衡里做「最不差」的决策。
聊架构设计的时候，我们在谈什么？
第一步是理解商业与组织上下文：利益相关方要什么，用户痛点是什么，商业指标如何定义成功，团队能力与文化能不能撑住方案。这些看起来「软」的问题，往往比技术选型更能决定架构会不会翻车。
第二步才把这些模糊诉求，收敛成可度量的架构特性与不可逾越的约束。可用性、弹性、可扩展性、成本、可演进性——每一项都要能回答「怎么量、量到什么程度才算够」。
四根柱子
书里把架构能力拆成四根柱子：架构特性、架构决策、架构风格 / 模式、以及架构的「软技能」——沟通、权衡、政治与引导。硬技能决定你能不能画对图；软技能决定图能不能落地。
Architecture is the stuff you wish you could get right early, because changing it later is expensive.
这不是号召提前过度设计，而是提醒：把「以后改不动」的决策提前显式化，把「以后还能动」的决策留到证据更充分的时候。
六步闭环
从商业理解 → 特性与约束 → 方案探索 → 决策与权衡 → 沟通落地 → 反馈与组织成长。闭环的最后一环常常被忽略：架构不只是一次交付，它会反过来塑造团队结构与协作方式。
读完之后我更愿意把「架构师」理解成一个持续做权衡的角色，而不是一次性画出终极蓝图的人。最不差的决策，往往来自对上下文的诚实，而不是对某一种风格的信仰。