我们总是会从老师那里听到关于软件架构之类的话，但是事实上并不怎么了解，通过这本书，我了解了更多的关于架构的知识。
软件架构是软件设计的高层部分，是用于支撑更细节的设计的框架。架构指的是适用于整个系统范围的设计约束，而高层设计指的是适用于子系统层次或多个类的层次上的设计约束（但不是整个系统范围的设计）。而且架构的质量决定了系统的“概念完整性”。继而决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，它为程序员提供了指引---其细节程度与程序员的技能和手边的工作相配。好的架构使得构建活动变得更容易，糟糕的架构则使得构建活动几乎寸步难行，在构建期间或者更晚的时候进行架构变更，代价也是高昂的。
系统架构首先要以概括的形式对有关系统做一个综述。在架构中，我们应该能发现对那些曾经考虑过得最终组织结构的替代方案的记叙，找到之所以选用最终的组织结构，而不用其他替代方案的理由。描述其他组织结构，才能说明架构最后选定的这种系统组织结构的缘由，并且表明各个类都是慎重考虑过的。有一份对设计实践的综述发现，“维护”设计的缘由至少与“维护设计本身”一样重要。
架构应该定义程序的主要构造块。根据程序规模不同，各个构造块可能是单个类，也可能是由许多类组成的一个子系统。每个构造块无论是一个类还是一组协同工作的类和子程序，它们共同实现一种高层功能，诸如与用户交互、显示web页面、解释命令、封装业务规则、访问数据等等。每条列在需求中的功能特性都至少应该有一个构造块覆盖它。如果两个或多个构造块声称实现同一项功能，那么它们就应该相互配合而不会冲突。
应该明确定义各个构造块的责任。每个构造块应该负责某一个取余的事情，并且对其他构造块负责的区域知道的越少越好。通过使各个构造块对其他构造块的了解达到最小，你能将设计的信息局限于各个构造块之内。对于每个构造块，架构应该描述它能直接使用哪些构造块，能间接使用哪些构造块，不能使用哪些构造块。
架构应该详细定义所用的主要的类。它应该指出每个主要的类的责任，以及该类如何与其他类交互。架构应该描述所用到的主要文件和数据表的设计，应该详细定义所用数据库的高层组织结构和内容。架构应该描述一份管理稀缺资源的计划。架构应该描述实现设计层面和代码层面的安全性的方法，在架构阶段建立威胁模型。
架构不应该包含任何对我们而言很难理解的东西，因为我们就是那个实现架构的人。