翻开这本书之前对架构的理解是很模糊的，之前总是听老师再说架构什么的自己其实一直都不理解何为架构。在书本的开头作者就明确的告诉我们架构是什么？架构是架构师洞见一个待开发系统的内在的结构、规律、原则和逻辑的过程，而不是一个已经完整显示出来的，可以画出图纸的结果。优秀的架构师可以将自己放在系统中去的，在清晰地理解了系统之后，简洁地描述出构建好的体统架构。当架构师拿出他所描述的“作品”的时候，事实上架构这一过程就已经结束了。
好的系统架构展示了架构完整性。也就是说，它来自于一组设计规则，这组规则有助于减少复杂性，并可以用于指导详细设计和系统验证。设计规则可能包含特定的抽象，这些抽象总是以同样的方式使用，诸如虚拟设备等。这些规则可能表现为一种模式，如管道和过滤器。在最理想的情况下，存在一些可以用于验证的规则，如“在设备失效时，所有某一类的虚拟设备都可以用任何其他同类的虚拟设备代替”，或“所有竞争同一资源的进程必须具有相同的调度优先级”。
当代的架构师可能会说，待构建的对象或系统必须具有以下特征：
- 具备客户要求的功能。
- 能够在要求的工期内安全地构建。
- 性能足够好。
- 可靠性。
- 可用的，并且使用时不会造成伤害。
- 安全的。
- 成本是可以接受的。
- 符合法规标准。
- 将超越前人以及竞争者
软件开发项目需要一些人在软件构建时扮演架构师的角色，就像构建或修复建筑时传统的建筑师的角色一样。但是，对于软件系统来说，从来就弄不清楚哪些决定属于架构师的职责范围，哪些决定要留给实现者。定义架构师在软件项目中做什么，比建筑时的类似定义更困难，原因有三个因素：缺少传统、产品无形性和系统复杂性。好的架构师通常来自更好的架构师的现场指导。原因之一可能是有一些关注点几乎在所有项目中都会出现。架构师在项目过程中需要考虑的其实有很多诸如：
- 功能性（产品向它的用户提供哪些功能？）
- 可变性（软件将来可能需要哪些改变？哪些改变不太可能发生，不需要特别容易进行这些改变？）
- 性能（产品将达到怎样的性能？）
- 容量（多少用户将并发使用该系统？该系统将为多少用户保存数据？）
- 生态系统（在部署的生态环境中，该系统将与其他系统进行哪些交互？）
- 模块化（如何将编写软件的任务分解为工作指派（模块），特别是这些模块可以独立地开发，并能够准确而容易地满足彼此的需要？）
因而架构不易，需要我们在实际的实验和项目中不断的总结和理解，软件架构还是需要多看，多学习了解其它的系统是怎么做的，有哪些可用的组件，对各种方法有思考有借鉴，最终形成自己的想法才是干货。工作和学习当中，还是要多花时间进行思考和设计，不要太急于动手了。