1 · 读书笔记：软件架构基础

Fundamentals of Software Architecture

https://book.douban.com/subject/37530051/

• 是什么（What）— 理论/原则，建立认知模型
• 为什么（Why）— 背后的动机、约束与权衡
• 怎么做（How）— 技巧 + 实践 + 边界（该做与不该做）

1.1 · 核心观点：

软件架构的本质是权衡（trade-off），没有完美的架构，只有在特定上下文中最合适的架构。

• 软件架构 = 结构（Structure） + 架构特征（Architecture Characteristics） + 架构决策（Architecture Decisions） + 设计原则（Design Principles）
• 架构师的核心职责：做架构决策、持续分析架构、紧跟技术趋势、确保团队遵循决策、拥有广泛的技术广度
• 架构风格不是孤立选择，而是由业务驱动力和架构特征共同决定的
• 架构师必须在 3-5 个关键架构特征上做取舍，试图优化一切只会得到平庸的”通用架构”

1.2 · 启发点（关键洞察）：

1. 架构思维 ≠ 技术深度，而是技术广度：开发者追求深度（stuff you know），架构师追求广度（stuff you know you don’t know），需要在深度和广度之间找到平衡
2. “Why” 比 “How” 重要（架构第二定律）：记录架构决策背后的动机（ADR），比记录具体实现更有价值；未来的人需要理解”为什么这样选”
3. Service-Based 架构是最务实的架构风格之一：4-12 个粗粒度领域服务，介于单体和微服务之间，兼顾简单性和可部署性
4. 模块化是架构的基石：内聚性（Cohesion）、耦合性（Coupling）和连接性（Connascence）是衡量模块化的三个维度
5. 架构师 50% 的工作是非技术性的：沟通、谈判、领导力、演示、政治导航——技术能力是入场券，软技能决定成败
6. 演进式架构（Evolutionary Architecture）：架构不是一次性设计，而是通过适应度函数（fitness functions）持续验证和演进的

1.3 · 行动：

1. 在项目中使用 ADR（Architecture Decision Records） 记录每个重要架构决策的上下文、决策和后果
2. 对当前系统做一次”架构特征分析”：识别出最关键的 3-5 个 -ilities（可用性、可扩展性、可测试性等），检查架构是否真正支撑了它们
3. 培养技术广度：建立”技术雷达”习惯，定期了解新技术/架构风格，不需要精通但要知道其存在和适用场景

1.4 · 金句：

1. “Everything in software architecture is a trade-off.” — 软件架构第一定律
2. “Why is more important than how.” — 软件架构第二定律
3. “If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet.”
4. “There are no right or wrong answers in architecture — only trade-offs.”
5. “An architect who codes is still an architect, but an architect who doesn’t code is just a talker.”