关于分阶段，每个阶段在多视图。我觉得做一件事情是要以时间轴来看。更广泛一点，应该是主题来看。一个主题，我们可以有多种视角。拿时间来说，我们确实会分步骤去做长期的实施计划。
关于二维需求矩阵。一个维度是功能质量约束，没啥问题。但另外一个维度是说组织、用户和开发，这里问题比较大，因为从理论上来说，我们应该考虑涉众及其利益，包括boss、客户、用户等。研发是一个过程，他却把里面的很多点都放进去了，涉及软件工程。维度不怎么合理、差一点理论。我觉得他把组织和用户分开适合面向互联网to c的场景。好比一端是商户的需求，一端是用户的需求。目标和涉众，应该是更科学的划分。
第一章 概论
- 软件架构在不断发展，但仍然是一个尚不成熟的学科。
- 架构设计能力，因掌握起来困难而显得珍贵。
一线架构师6个经典困惑
四个实际问题的困惑
1.将系统划分模块，如何更合理？
2.大系统架构设计，如何起步？
3.总觉得需求很糟糕，影响了架构设计！
4.非功能需求重要，但如何设计？
两个职业发展的困惑
1.架构新手：缺乏指导，架构设计不知所措！
2.架构老手：缺乏总结，仍怕下个项目。
该书的四个核心主张
- 方法体系是大趋势
一线架构师真正需要的，是覆盖需求进、架构出全过程的实践指导--只有综合了不 同方法优点的“方法体系”才堪此重任。方法体系必然是软件业界未来发展的重大趋 势 - 质疑驱动的架构设计
从根本上讲，架构设计是需求驱动的，而不是模型驱动的。架构设计是一门艺 术，你不可能把“一桶需求”倒进某台神秘机器，然后等着架构设计自动被“加工”生 产完毕，这里缺的是架构师的因素。 架构设计实际上是一个“质疑驱动的过程”：需求被架构师的大脑有节奏的引入架构设计一波接一波的思维活动中。 - 多阶段方法
先做后做--叫做阶段；齐头并进 --这是视图。任何好的方法，都必须以时间轴来组织，这样才最利于指导实践。 - 内置最佳实践的方法
方法不应该是个空框框，应融入最佳实践经验