翻开这本书之前对架构的理解是很模糊的，之前总是听老师再说架构什么的自己其实一直都不理解何为架构。在书本的开头作者就明确的告诉我们架构是什么？架构是架构师洞见一个待开发系统的内在的结构、规律、原则和逻辑的过程，而不是一个已经完整显示出来的，可以画出图纸的结果。优秀的架构师可以将自己放在系统中去的，在清晰地理解了系统之后，简洁地描述出构建好的体统架构。当架构师拿出他所描述的“作品”的时候，事实上架构这一过程就已经结束了。
好的系统架构展示了架构完整性。也就是说，它来自于一组设计规则，这组规则有助于减少复杂性，并可以用于指导详细设计和系统验证。设计规则可能包含特定的抽象，这些抽象总是以同样的方式使用，诸如虚拟设备等。这些规则可能表现为一种模式，如管道和过滤器。在最理想的情况下，存在一些可以用于验证的规则，如“在设备失效时，所有某一类的虚拟设备都可以用任何其他同类的虚拟设备代替”，或“所有竞争同一资源的进程必须具有相同的调度优先级”。
当代的架构师可能会说，待构建的对象或系统必须具有以下特征：
软件开发项目需要一些人在软件构建时扮演架构师的角色，就像构建或修复建筑时传统的建筑师的角色一样。但是，对于软件系统来说，从来就弄不清楚哪些决定属于架构师的职责范围，哪些决定要留给实现者。定义架构师在软件项目中做什么，比建筑时的类似定义更困难，原因有三个因素：缺少传统、产品无形性和系统复杂性。好的架构师通常来自更好的架构师的现场指导。原因之一可能是有一些关注点几乎在所有项目中都会出现。架构师在项目过程中需要考虑的其实有很多诸如：
因而架构不易，需要我们在实际的实验和项目中不断的总结和理解，软件架构还是需要多看，多学习了解其它的系统是怎么做的，有哪些可用的组件，对各种方法有思考有借鉴，最终形成自己的想法才是干货。工作和学习当中，还是要多花时间进行思考和设计，不要太急于动手了。
原文地址：http://www.cnblogs.com/Againzg/p/6384497.html
