架构是什么，对于很多人像我们这样的初学者来说可能都不清楚，还有更多的人分不清楚架构、框架、模式和平台的区别，它们各自是什么东西。都是模棱两可的。这几天通过上网查询，设计模式<框架<架构<平台，从复用角度讲，设计模式是代码级复用、框架是模块级复用、架构是系统级复用、平台是企业应用级复用。而对于我来说在此之前听得最多的或许是框架。对于框架来说，框架就是一组协同工作的类，它们为特定类型的软件构筑了一个可重用的设计；框架其实就是某种应用的半成品，就是一组组件，供你使用完成你的系统；框架总是解决应用中某个领域的问题；那么什么是架构呢。
软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解。体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)。对于建筑来说好的建筑应该美观，坚固，实用。对于架构可以说是这三方面的一种平衡和配合，没有哪一个方面比其他方面更重要。架构观点中的常见思想是结构 ，每种都由各种类型的组件及其关系构成。当一个软件架构师创建软件系统的架构时，他的关注点是什么呢，是对系统进行组织，让每种结构有助于解答一个关注点所定义的问题。好的架构应该能经受的住评估，检验最终的性能。一些足够好的架构，值得我们去珍视、去学习，值得我们每个人了解并掌握。
紧接着作者使用一整章的内容通过两个软件系统的开发实例来为我们展示了架构的重要性。在“混乱大都市”中让我了解到开发团队中健康的工作关系将直接有益于软件设计。不健康的关系和个性膨胀会导致不健康的软件。好的设计考虑到内部组件连接的连接机制和连接数（以及连接性质）。系统的单个部分应该能够独立存在。紧耦合将导致不可测试的代码。但是在“混乱大都市”中缺少预见性和架构设计，导致了一些问题。比如说低品质的软件和漫长的版本发布周期，系统没有弹性，不能够适应变更或添加新的功能，无处不在的代码问题，员工问题（压力大、士气低、跳槽等）等等等等。在“设计之城”中我学会了架构有助于定位功能：添加功能、修改功能或修复缺陷。它为你提供了一个模板，让你将工作纳入到一张系统导航图中。清晰的架构设计将导致一致的系统。所有决定都应该在架构设计的背景下做出。清晰的架构有助于减少功能重复......好的架构是很多因素的结果，包括有意为之的前端设计，设计者的素质和经验。（以前犯过一些错误是有帮助的，这能在下一次为你指出正确方向！“大都市”项目肯定教会了我一些东西。）在开发过程中，保持清晰的设计观点。