整部书由23位知名人士撰写，每个人都久负软件设计相关经验，给出很多具有实际指导意义的架构设计实践。有趣的是本书一直强调软件架构的概念一致性，即架构设计需要上下文和谐与统一，但是编写本书却是集各家之言，很难保证他们所思所想是一致地，因此本书需要有一个清晰的框架准则来约束编写者。这个框架准则就是编者要有相同的关注点：让优秀的设计师和架构师来描述他们所选的软件架构，一层层剥开架构的“心”，展示架构是如何让软件实现以下这些特性的。
阅读本书能够清晰地捕捉到文章脉络，在前言中介绍了书的组成，在没有看前言的 前提下，读者也能够从一章的叙述方式推演到其它章节的叙述方式（举一反三），降低理解的成本，让读者心旷神怡。
全书有5部分，因为笔者是基于Web做后端开发，省略第三部分没看。等有需要的时候再着重阅读。极限编程的思想是不想太多，马上码代码，把重点功能搞出来，设计可以延时来做。与之对应，在阅读本书时，笔者采用极限阅读的思想，先阅读，然后摘抄和记笔记，分析可以延时考虑。
其实再思考一下架构这玩意和写博客何其相似，博客需要清晰的框架，好的框架对读者和作者都有好处，读者能够从优秀的博客中快速获取到需要的内容，作者在写作时能够得到享受，如章节的扩展、补充、修改都是一件件容易的事情。
一、什么是软件架构正如《道德经》第一章所言：“道可道，非常道。”架构可以说是一种“道”，美的架构是“非常道”，需要经过长时间的训练才可以执行和落地。软件架构的定义不统一，但描述相对完备的如《Software Architecture in Practice》所讲：“软件架构是系统的一种结构或一组结构，包含软件元素、这些元素的外部可见属性以及元素之间的关系。‘外部可见’的属性指的是其它元素对该元素的假设，诸如它提供的服务、执行时的特征、错误处理、共享资源的使用等”。
架构的表现形式是分层结构，特征是概念完整性。
架构设计保持概念完整性的好处：
- 让开发者了解系统的一部分后，能够迅速理解系统的其它部分；
- 让开发者运用在系统的一部分工作经验，来开发和维护系统的其它部分；
两种评估方式：
- 通过建模或者模拟系统的一个或多个方面来确定架构的属性
性能模型、失效树模型等； - 通过对架构师提出质询来评估（使用广泛）
架构折中分析方法、主动复审方法。
| 名称 | 来源 |
|---|---|
| A-7E舰载飞行处理器 | 美国海军研究实验室 |
| 5ESS电话交换机 | 朗讯 |
| 万维网 | 蒂姆·伯纳斯-李（Tim Berners-Lee） |
| UNIX | 丹尼斯·里奇、肯尼思·汤普森 |
- 同时关注功能和性能且后者是首要关注点；
- 让利益相关人员参与；
- 创建架构保持一种思考方式和哲学；
关注点包含：
